Worst "in production" microcontrollers - Page 1
Forum section: electronics / general

author: benSTmax
author_rank: Regular Contributor
timestamp: July 29, 2022, 10:44:03 pm
content: Nowadays, with all the shortage, we're sometimes forced to redesign due to unavailability of the original micro.The choice is to use some alternate micro from the same manufacturer(as the original) or from a different silicon vendor because one can still buy maybe a few hundreds of them.Some of the available micros(available in hundreds of pcs) have some really nasty silicon bugs, though they're still being manufactured.Which are some of the worst (I mean serious bugs without real workarounds) microcontrollers you all encountered in the past 10 years or so and still in production?

author: brucehoult
author_rank: Super Contributor
timestamp: July 29, 2022, 11:48:43 pm
content: Oh, you're talking about bugs.PIC has to be the worst, by design, atrocity that is still in production. Let's include Padauk in that. Even 8051 is a lot better.

author: nctnico
author_rank: Super Contributor
timestamp: July 30, 2022, 12:04:25 am
content: Add ST's STR700 series microcontrollers to the list. A complete joke.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 30, 2022, 02:53:25 am
content: Pic32 were a mess, specially the MZ series.But stm32 have serious bugs too!8/16bit pics weren't too bad, some weird peripheral sh** from time to time, in the end we just disabled/enabled the peripherals after a transfer was done instead fighting/figuring out the bugs.

author: uer166
author_rank: Super Contributor
timestamp: July 30, 2022, 02:57:59 am
content: Quote from: DavidAlfa on July 30, 2022, 02:53:25 amThis might be a case-by-case basis. I've had pleasant experiences with the MX series, and some things were done better than your run-of-the-mill STM32. Can't speak for MZ though, except hearing about a lot of bugs in the early revisions.

author: IDEngineer
author_rank: Super Contributor
timestamp: July 30, 2022, 04:29:13 am
content: Quote from: brucehoult on July 29, 2022, 11:48:43 pmI don't think that's fair. The PIC processing core is atrocious, that's true, but unless you're writing Assembler the compiler will isolate you from the weirdness. I'm told the paid version(s) of the compilers are substantially better at optimization, but so far the free version(s) have been sufficient for my purposes.The PIC peripherals are pretty good IMHO. They take a bit of study, and you should always write your own code to initialize and control them (as opposed to the various canned libraries), but many times I've found that something which appeared "weird" at first turned out to be surprisingly useful. Almost like the architecture Engineers had done some actual embedded development themselves! {gasp}I give high marks to Microchip for their documentation. ESPECIALLY compared with other MCU's. What you need to know is in there. Occasionally it's arranged a little strangely, but you'll find it. And it reads like it was written by English-as-first-language authors and not some Google Translate beta test.

author: jpanhalt
author_rank: Super Contributor
timestamp: July 30, 2022, 09:14:03 am
content: In defense of PIC, I agree Microchip's documentation is quite complete and understandable. There are a few typo's and/or cut and paste errors that don't seem to get fixed very timely. Context with other chips in the same series usually helps. As for the Harvard structure, I program in Assembly and don't have a problem with it at all. It gets easier as core size increases. Twelve-bit cores are tough. Fourteen bit cores are significantly easier and are what I use almost exclusively. Sixteen bit or more are not much of a problem as the address range is quite large.Silicon errata are inevitable. Are other manufacturers perfect? Do they publish easily accessible errata? Usually, just being aware of them is all that's needed. Some are surprising -- like not being able to reliably use an instruction like "bra" (relative branch) with a few revisions. Very early on (1990's) there was a problem with clearing GIE and interrupts. Microchip promptly added the work around to its datasheets for the affected chips. That affected only 3 chips (16C71, 16C73, and 16C74), yet rumors spread that all 16F/C chips were affected. Of course it was fixed with later silicon versions of the 16C73/74 and did not affect any other chip.What bothers me is not the errata per se, but the inability to easily order by revision number from DigiKey or Mouser and maybe every other supplier too. One is left hoping you get sent a newer chip. At least that's the way it worked earlier this year when I wanted a specific silicon version. Maybe that only applies to small orders too.

author: benSTmax
author_rank: Regular Contributor
timestamp: July 30, 2022, 09:48:09 am
content: The worst offenders in my case are the PIC32MZ EC and SAM V70PIC32MZ EC's peripherals were riddled with serious bugs. Good thing this abomination is on NRND.Don't get me wrong. I am not bashing Microchip. I had really good experiences with PIC32MX270 and I like a lot the PIC32MZ EFSAM V70 was a bad experience for my company too. A few hundreds of 64 pin variant were ordered just to find out the USB wasn't working at all in the 64 pin packages. This teached everyone at my workplace to check the errata at the same time with the datasheet.At least, the latest SAM V70 datasheet shows there's no USB on 64 pin variants (the errata still says the USB is not working on 64 pin variants)We're trying to avoid SAMs with SERCOM which is another nightmare-ish peripheral. Plenty of issues with I2C and SPI, thus I am trying to avoid it like plague and the SAM micros using it. Microchip should either fix and improve this peripheral or scrap it.I would add the SAM datasheets as probably the worst ones (at least in my view).STM32F3xx series had some annoyances but nothing to seriously affect the designed board (in contrast with the V70 where USB wasn't working at all)On a positive note, I absolutely loved the experience with NXP's Kinetis MKL27Z

author: voltsandjolts
author_rank: Unknown
timestamp: July 30, 2022, 11:06:11 am
content: Last time I used NXP parts they were Philips 8051I've heard some good things about NXP and I need to try their modern stuff.You say the KL27 was nice, what tool chain did you use and how was it?

author: benSTmax
author_rank: Regular Contributor
timestamp: July 30, 2022, 11:41:41 am
content: Back in the day the Freescale IDE was called Kinetis Studio and it was Eclipse-based. The toolchain was GNU GCCI played in the beginning with their FRDM-KL25Z board using both Kinetis Studio and Keil.I think Freescale was one of the first micro companies to offer a code configurator(called Processor Expert) for most of their peripherals. In my case, this was helpful because I had no prior experience with Kinetis peripherals and it gave me a good head-start. Of course, later on I rewrote some of the drivers to be simpler and better aligned with my style.After the successful experience with KL25(on the dev kit), the company I work for designed a custom board around KL27Z. When the custom board came from assembly, I just loaded a board test project I created using Kinetis Studio and Processor Expert and everything worked.

author: JPortici
author_rank: Super Contributor
timestamp: July 30, 2022, 11:50:35 am
content: Quote from: IDEngineer on July 30, 2022, 04:29:13 amNot since they acquired atmel. Atmel documentation was shit and microchip documentation since they acquired atmel has become shit. Written badly, lots of information missing, datasheet format changed so that a 300 page document has become 500+ page with zero added information, it's just the layout with nonsensical page breaks, unreadable graphs and so on. Wouldn't have minded if atmel doc style stayed with atmel partsThe worst in production microcontrollers.. I guess those which i find the worst to work with, so worst dev tools. That's going to be Silabs and STM for mesilabs make it so freaking hard to get docs, so many times i had to fill a request form for a freaking datasheet or demo code for their own dev boards. I wonder what would have happened if i didn't sign up with the work email. And their examples on 8051 parts use SDCC (which i hate) and 4-5 level deep macros with preprocessor tricks for everything (which i hate even more)STM, never understood why they got the appeal. dsPIC and PIC32MX run laps over their cortex M0/M3/M4 (non F) and the peripherals were on par with a PIC18 of the time. I'll take 5V over 32bit thank you. Docs are so horrible and erratas for some parts are hard to find. I haven't programmed with them in a while but i remember that when i started with them setting up the toolchain with eclipse + gcc + plugins + openocd made me want to wildarize the discovery board. And openocd was so slow and prone to failure that i didn't understand how all those neckbeards could rant against the Pickit 3 when that was the alternative. It was several years before CUBE came out, we were using their first hal for which all the docs were some autogenerated doxygen crap. Now things are way better but i will still use any other ARM parts if i really have to use one (possibly Kinetis or ATSAM)

author: rooppoorali
author_rank: Regular Contributor
timestamp: July 30, 2022, 12:37:28 pm
content: Original microcontrollers are rare where I live.....

author: Kjelt
author_rank: Super Contributor
timestamp: July 30, 2022, 12:38:37 pm
content: Any fancy ARM based microcontroller from Broadcom, the reason being you can't get a decent datasheet/reference manual etc. unless you are a real big client, then the NDA's and lawyers visit you. At least that was our experience a couple of years back.

author: hans
author_rank: Super Contributor
timestamp: July 30, 2022, 09:29:08 pm
content: PIC32MZ EC as mentioned. If you scroll through the errata, I would be amazed if anyone was able to get a working board out the door. Tons of pin mux issues, frequency sources/specifications not working, power management features that are buggy (and are a total PITA to track down) etc.I've had some annoying quirks with SiLabs MCUs as well. IIRC on either the original Gecko or Happy Gecko's, the peripheral bus had to synchronize on the LFOSC domain to perform any writes to the RTC. This was problematic when you use the lowest power oscillator, that domain only runs at 1kHz... so the CPU running at dozens of MHz is stuck in a spinlock for 1ms. Bit of an oversight?I recall this being an issue because I was using the RTC for wireless time synchronisation (TDMA) and also as an alarm wakeup source for the kernel I had built.Quote from: JPortici on July 30, 2022, 11:50:35 amI've used some PIC32MX devices and quite the hardware simplicity and efffectivity. However I found the interrupt epilogue/prologue to be quite a mess, even with the shadow set registers is unnecessarily long. As it stands, a timebase IRQ on a MX250 project is taking in the order multiple microseconds @ 50MHz.Also, if someone can dig up a workingbuiltin atomicfor the XC32 GCC build, then that would be great.Concerning tools, my experience is the opposite. Openocd uploads with dozens kB/s to even the smallest chips (STM32L011), while on PICKIT3 and MX250 chip I've to wait almost a minute for a regular erase/program cycle of a 10kB binary (assuming the debugger connection is left open, because if not, that can also fail half the time -- and yes, I still use the original red USB cable with the PK3).Datasheets and erratas for ST and SiLabs aren't that hard to find once the website navigation is learnt. Only recently I have figured out I don't have to go the specific ST part number page to get to the PDFs. Just lookup the series, e.g. F42x/F43x series and then goto 'Documentation' actually has a very brief and clean list of relevant documents.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 30, 2022, 10:21:30 pm
content: there's no such thing as "best" or "worst", only more or less suitable to a particular application or situation.

author: benSTmax
author_rank: Regular Contributor
timestamp: July 30, 2022, 11:34:15 pm
content: Quote from: mikeselectricstuff on July 30, 2022, 10:21:30 pmWhen a micro has a few non-functional peripherals and there's no workaround for them (e.g. USB in V70 64 pin) that to me is a good candidate for "worst" parts that you can still find available in these chip shortage times.Of course, you can still use it for non-USB based applications but in this case one might still be able to achieve the same with a micro which costs far less than the $10-$12 price tag of a V70

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 31, 2022, 12:53:52 am
content: Quote from: JPortici on July 30, 2022, 11:50:35 amEh? I found, at least the classic MEGAs (32, 328, etc.) very well formatted. The peripherals are simple, registers documented inline, and even example code is given in both ASM and C.I found the XMEGA+ documentation more frustrating, that the naming conventions are all more opaque. I've often found myself skimming through the io*.h header to find what the hell something is actually named. They do seem to use it consistently, at least, so it's usually just a few guesses nowadays to find what something is named. The most annoying recent example being AVR-Dx's bimorphic TCA (everything is TCAn_SINGLE_reg, etc.).Other than that, I found most XMEGA prose to be usable, no particular problems getting something to work. That the ADC is offset is...weird (single ended mode), but, it seems to do what it says on the tin, in any case.What I take issue with -- and I also get the impression of a slow decay in quality here -- is the AVR-Dx descriptions of peripherals, TCD in particular, but also TCA (and TCB could still be clearer). The organization is terrible, if you want to know some particular aspect you have no choice but to read the whole section front to back, hunting for any least bit relevant information. The explanation is far, FAR more complex than it really is (TCB in particular is guilty of this, being actually an extremely simple device, butmuch moreseems to be implied by the text!).Whereas, original Atmel explanations were helpfully redundant: every section is self-contained, repeating anything in common with other devices, so that you don't have to jump around to get the full picture. It's generalized just enough, so that you aren't left guessing about anything. (For example: you might only have TC0 and TC1/TC2, but each is explained as if there could be multiple; on low end parts, it's true, while on bigger parts, you have many to choose from -- well, moreso with USARTs and such, than timers, but you get many more of both on XMEGAs for example.)I think they've taken the same tack that a lot of other manufacturers have: outsourcing not just manufacturing, but service, and indeed now engineering as well. Combined with the contraction/ongoing restructuring of labor forces these days, there's altogether less engineering support, less responsible management thereof, and less quality oversight, of these processes.TI for another example, is headed full steam into this layout. Of this, I am sure. There are too many signs of dropped quality, and design, and service, that are outwardly visible. I have no idea how much they still have in the west, but I can't recall ever seeing a non-Indian name on their e2e forum, so, that's service engineering outsourced at the least. I actually had an online meeting with one the other day (about an unrelated chip), and he admitted he doesn't know what or why sales/marketing is doing what they're doing -- he tells me the chip in question is NRND, but you wouldn't know that based on its product page or lifecycle status(!!!).So, for MCP, I suspect the problem is, not only has service and documentation been moved over to India or other low-cost countries, but there are poor oversight/management/quality processes in place to handle it. Mind, their grammar is excellent -- I don't recall spotting a typo. It's well written, at face value, as English goes. Presumably, the techs/engineers they've hired, are near/at the top of their field; I have no problem with that at all. But there is still so much missing, that a couple also-top-of-field editors or managers or QC crew could cover, and it's just... there's no connections there, it's all dropped on the floor and left to rot. So we get documentation that is, despite being facially well-written, is just so poorly organized and non-descriptive.QuoteOh yeah, that reminds me of one I recall... FTDI Vinculum apparently is shite.That was enough years ago (almost a decade actually, heh), so besides FTDI being lower market share nowadays(??), the whole line maybe is irrelevant? But, as things go, that was what I heard...Have also heard negative about Si, but no direct experience.1st/2nd hand experience with STM: middling. It's economy market: cheap parts, for everything that word entails. They're good for what they are, low enough bugs/errata, and powerful enough libraries and tools, that you can do real work without having to spend infinite digression dealing with bugs -- you still will spend some time on them, sure, but not most of your time. And the result will be bloated, sure, but not so badly that you're prohibited from making a thing. They have ample Flash and RAM to handle their shitty libraries. Optimization doesn't sell products, products sell products. Make the thing first, cost reduce it later -- if it even makes sense to at all.Analogous to other things that people complain about, but not so badly as to give them up (or drive them to make newer/better). JS, Python, etc.; whether by themselves, or more particularly with the various libraries and ecosystems i.e. NPM, PyPI, etc. they're typically used with. They might suck, but not so badly as to want to go and fix the problems yourself (rather than work around it), and you're still making productive* applications.*Again, in the most basic and most important sense: i.e., it earns money on average.Tim

author: brucehoult
author_rank: Super Contributor
timestamp: July 31, 2022, 02:02:22 am
content: Quote from: T3sl4co1l on July 31, 2022, 12:53:52 amFunnily enough I happened to look into that a week ago when I got curious what ISA FTDI uses. I don't know if their parts other than VNC2 use the same CPU core, but I assume so.It's pretty awful.https://www.reddit.com/r/RISCV/comments/w5nduu/comment/ih9o9e2/It doesn't have any registers to speak of -- just program counter, stack pointer, status register, and a shadow status register.The C compiler uses the first seven 32 bit words of RAM as pseudo registers, a bit like 6502 Zero Page, I guess. I didn't find instruction encoding docs only the assembly language but it looks as if probably the first 4k of RAM is directly addressable.The real WTF thing is the names the compiler labels the seven pseudo registers as in the generated assembly language:0x00: %eax0x04: %ebx0x08: %ecx0x0C: %r00x10: %r10x14: %r20x18: %r3

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: July 31, 2022, 08:12:15 am
content: I bought in an atsame 21nxx for a USB project.RS components listing says it does USB and so does datasheet.Result is USB failed to work.Got in touch with Microchip who told me USB doesnt work on 64 pin version of chip and I should always read errata sheet first.SO had to buy in 100 pin devices and redesign part of pcb.

author: westfw
author_rank: Super Contributor
timestamp: July 31, 2022, 10:11:53 am
content: I had hopes for the FTDI vnc2 (TWO USB host/device controllers!) but got put off by the lack of info on the cpu architecture. “Just use our compiler and sdk and don’t worry about it.” Hmmph.I’m not sure that “using the low memory as registers” is so much different than “the low register are also addressable as memory” (avr, pdp10, etc.). Depends on timing, I guess. But timing info was one of the things lacking. Sigh.

author: David Hess
author_rank: Super Contributor
timestamp: July 31, 2022, 10:45:52 am
content: Quote from: brucehoult on July 29, 2022, 11:48:43 pmI do not think PIC is any worse than the 6502. That is just how accumulator based processors work.

author: brucehoult
author_rank: Super Contributor
timestamp: July 31, 2022, 11:47:40 am
content: Quote from: westfw on July 31, 2022, 10:11:53 amIt's logically the same thing, of course, but there are a number of performance and code size implications.A nice thing about having 3 or 4 or 5 bit fields for register numbers is that you can fit several of them into a relatively small instruction.If you look at that VNC2 code I deciphered ...Code:f200 800c PUSH32 %r0 # %r0 at 0x0cf200 8010 PUSH32 %r1 # %r1 at 0x10f200 8014 PUSH32 %r2 # %r2 at 0x14131b 8010 SP_RD32 %r1 $27 # 27 = 0x1bde00 0010 0002 0000 CMP32 %r1 $24400 8010 000c CPY32 %r0 %r1... it is apparent that each "register" reference in an instruction is adding 16 bits to the instruction. %r1 sometimes appears there as 0010 and sometimes as 8010. I'm not sure what the set hi bit does. I think that is some kind of part of the opcode, and there is some ability there to add indirection too. So the actual register address part is probably 12 bits.So that is vastly less program size efficient than if you had, say, 16 registers and could use a single hex digit to name each of the source and destination registers.Every single one of those instructions would be a single 16 bit MSP430 instruction, for example. Oh, except the "SP_RD32 %r1 $27". Everything except the compare would be a single 16 bit instruction on RISC-V.It may or may not be that their hardware provides faster access to the first few dozen bytes of "RAM", akin to registers, like on AVR. We don't know.If you ever want to make a fast implementation of an ISA then there is a big advantage to register references being effective names not numbers. What I mean by that is a register can only be read or written by an instruction which has the actual register number visible in a field in the instruction (or implied by it, as PC and SP and LR often are). If any pointer in the program can potentially refer to a register then you can't do register dependency tracking in a pipeline. If every store instruction can potentially change the contents of any register then you can't just put stores in a store queue and let them complete at leisure. If every load instruction can potentially depend on the result of every previous instruction then you can never get one started early. You can't even do a dual-issue in-order implementation like Cortex A7/M7/A8/A9/A53/A55 where arithmetic and load/store issue into parallel pipelines, because you can't tell whether there is a dependency between them until they get to the execute stage.

author: brucehoult
author_rank: Super Contributor
timestamp: July 31, 2022, 12:11:15 pm
content: Quote from: David Hess on July 31, 2022, 10:45:52 amIt's not being accumulator-based that is the problem. That's just a simple engineering tradeoff between fewer long instructions or more short instructions, with the end result being much the same, and all options are usable.The same goes for conditional skip instead of conditional branch. I really don't care.Things I seriously object to:- being too lazy to implement carry between low and high halves of addresses, even for the program counter. Sure, the 6502 adds a clock cycle if either a relative branch or indexed addressing crosses a page boundary, but at least it DOES it.- the TEENSY stack, only 2 subroutine call levels on some devices and a maximum of 8 on most. And the complete inability to use it for anything except call/return. You can't push a register and pop it back later. You can't index into the stack. People complain about the stack on the 6502 being only 256 bytes, but that's 128 subroutine levels deep! And you can stash register contents there temporarily. And if you keep 0x01 in a Zero Page location N+1 and do "TSX;STX N" then you can use "LDY #m;LDA (N),Y" to index into the stack.- the INDF support for pointers and structs and arrays in RAM is far worse than 6502.

author: JPortici
author_rank: Super Contributor
timestamp: August 01, 2022, 05:38:25 am
content: Quote from: T3sl4co1l on July 31, 2022, 12:53:52 amTry ATSAMalmost all new device datasheet and erratas are written in the ATSAM layout

author: JPortici
author_rank: Super Contributor
timestamp: August 01, 2022, 05:51:41 am
content: Quote from: brucehoult on July 31, 2022, 12:11:15 pmbruce, you should try some parts from this century, I can't even recall a partnumber that has two level deep stack... the PIC10 that cost a couple of cents? the PIC16F84A had 8 deep level stack. Current parts have a 31-255 level stack, multiple INDF sets that can access the whole memory linearly (no paging) and the compiler's actually using them, and Add to INDF instructions (but i'm not sure if they are used, probably in the paid "pro mode")they have sort of evolved over time.. one of the parts i use the most is the PIC18 K42 series

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 01, 2022, 05:52:25 am
content: Quote from: JPortici on August 01, 2022, 05:38:25 amAh, is that where that came from, then?Don't think I've looked at ATSAMs before MCP so I also have no opinion on those, alas.Tim

author: Berni
author_rank: Super Contributor
timestamp: August 01, 2022, 06:35:55 am
content: PICs are not that bad to use in practice.The documentation for PICs is pretty good and the peripherals are nice and simple without much unnecessary baggage. Bugs happen here of there but typically have some workaround. The docs and peripherals on STM32 chips tend to be a lot worse in some places (Like even I2C just locks up and needs turning it off and on again)The actual CPU inside the 8bit PICs is indeed an atrocious architecture. Getting anything done needs a lot of instructions, it has was too few registers, weird hardware stack etc.. The core parts of the architecture date back to the 1970s and because it had to be cheap it meant it had to use the bare minimum number of transistors. This is why the core is so crappy, it has the bare minimum to run a useful program. This design was then slightly updated and dragged on into the modern times. Microchip probably likes it because it still uses a tiny number of transistors. The C compilers for it have also gotten pretty good so it hides it away from you while also making reasonably optimized machine code, making programing for it not that bad at all. They are cheap and do the job for when you don't need performance.Back when i was using mostly PICs i tended to rather use the 16bit ones (PIC24F, PIC33F, dsPIC etc..) since those have a more modern core design that is better suited for running C code and can address memory more sensibly.If you need a brand name cheap 8bit MCU it is probably more sensible to go with AVR. They are cheap lil simple low power MCUs but have a better CPU architecture.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 01, 2022, 06:50:59 am
content: The irony of transistors is, they're essentially zero-cost now. In fact the AVR-Dx series, I'm pretty sure, is using a new fine-pitch process. There's very little hint about it, but enough to be sure:QuoteIt doesn't make it out to a pin (apparently they solved compensation/bypassing well enough to not even need an external cap!), you'd never know it's there except for hints like this. Presumably then, they're running at, well, something less -- 1.2, 1.8V, something like that, and all the other peripherals are crammed in there along with the core. Then level shifters and IO cells complete the chip. (There's even a few with separate IOVCC domain(s).) Hence why they can offer even more stuff than the XMEGAs contain.Possibly they're doing the same with newer PICs, which also come with increasingly ornate and numerous peripherals (I think a lot of the -Dx peripherals are inherited from existing MCP stuff??). The PIC core itself must be nearly unidentifiable among the sea of buses and gates and arrays.Those familiar with PIC datasheets: is there any such mention of stuff like this? In any family? Or, also I'd imagine PIC24 or 32 or ds might, or have for a while already, I don't know?Tim

author: brucehoult
author_rank: Super Contributor
timestamp: August 01, 2022, 07:45:17 am
content: Quote from: JPortici on August 01, 2022, 05:51:41 amIf you can take a PIC18 from 2000 then am I allowed an updated 6502 from 1983? All the registers are expanded to 16 bits, and the address space to 24.I bet there are a LOT of PIC16 still in use. Digikey etc certainly list a lot of them as active, and with sizes up to 4 KB RAM and 32k instructions.PIC18 only goes up to twice that size.The title of the thread is worst microcontroller still in production, and the PIC16 seems to be very much in production. Digikey finds twice as many active PIC16 part numbers as PIC18.Digikey shows 480 active PIC12 part numbers, and lots and lots of them are in stock. Yes, with a 2-level call stack, and maximum 256 bytes of RAM.

author: westfw
author_rank: Super Contributor
timestamp: August 01, 2022, 08:05:41 am
content: QuoteThe max stack depth on PIC16F1xxx chips is 16.max stack deptth on PIC16Fxxx is only 8.(most are better than 2, though. I count only 6 PIC16F chips with a stack-size of 2. (grepping through the PACKS directory of MPLAB))Most PIC18 chips seem to have a stack depth of 31 (?!), Except for a few J, K, and Q series chips with 80 or 127.PIC24, PIC30, PIC33, PIC32 are all swell, but are whole different architectures, and not what people usually mean when they say "PIC Microcontroller."

author: hans
author_rank: Super Contributor
timestamp: August 01, 2022, 08:11:49 am
content: Quote from: Berni on August 01, 2022, 06:35:55 amI don't think it's always the case the Microchip likes it, but they sure like paying customers that buy millions of chips. If those have 30 years of legacy code written in Assembler for the PIC16 core, then they have a financial incentive to keep making those chips.Obviously that also means newer chips with an extra SPI bus, higher resolution ADC and a bit more memory. But it still drags forward a lot of the old legacy, which is what it is.Indeed there are also plenty of users that don't really care about performance. That's also fair. It's easy to overengineer everything when latency or throughput isn't even on the requirements list. As long as it's good enough and bug free, then that's job done.

author: Berni
author_rank: Super Contributor
timestamp: August 01, 2022, 09:43:49 am
content: Some of the 16bit PICs do have internal Vcore regulators since they do need an external capacitor for it. The faster variants of the 16bit PICs did become pretty power hungry (in the 100s of mW) and so this was likely a way to help cut down the power consumption.The 16bit PICs ware an awkward middleground in general. They didn't have the performance of the bigger 32bit chips and they didn't have the low power capability of the 8bit chips. Since the 8bit PICs ware so low transistor count they could stick to very old chip fab nodes and they still ran well enough, but it made for terrible MIPS per Watt in the 16bit ones.Quote from: hans on August 01, 2022, 08:11:49 amIf its about legacy code they probably wouldn't have to design new PICs, they could just keep making the old ones.It is more that the PIC is one of the cheapest 8bit MCUs you can buy from the big distributors(Digikey Mouser Farnell..) that comes from a well known brand name and has a large user base of people who used them in the past. They keep designing PICs into products just because they know how to use them.But hey so do i. Every so often i still use a PIC when a really simple task for a MCU pops up. Sure a PIC12F barely has any brains in it, but it is enough to implement a timer or counter or PWM controller something.If you want to really scrape the bottom of the barrel there is the Motorola MC14500B (1 bit microprocessor):https://en.wikipedia.org/wiki/Motorola_MC14500BIt is hard to find where to buy one, but you can still find brand new chips if you look long enough.

author: voltsandjolts
author_rank: Unknown
timestamp: August 01, 2022, 02:57:42 pm
content: PIC16F are probably the least good most popular mcu core around ATM.Please stop buying them to make them go away.Oh, crap, I justdesigned one in.As for the worst in production...hmm, maybe a4-bit mcu with integrated 4-bit ADC?Or maybe it's the best device for it's target application and bom cost?

author: woofy
author_rank: Frequent Contributor
timestamp: August 01, 2022, 03:41:49 pm
content: Any micro-controller in which specified features do not work and never get fixed. (Looking at you, PIC32 EC).I'd certainly not include anything just because I didn't like the architecture.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 01, 2022, 03:56:19 pm
content: Quote from: voltsandjolts on August 01, 2022, 02:57:42 pmNobody cares what the core is. it's all about the peripherals ( and nowadays, availability).

author: IDEngineer
author_rank: Super Contributor
timestamp: August 01, 2022, 03:59:19 pm
content: Quote from: woofy on August 01, 2022, 03:41:49 pmLet's be honest: MCU's are incredibly complex devices. Not the highest transistor count perhaps, but billion+ CPU's have a lot of repetitive parts (example: on-die caches) and charge a lot more money. MCU's are inexpensive and have a wide variety ofdifferentperipherals, so architecturally they would have more opportunities for flaws.It's been a long time since I used something as complex as an MCU that had ablankerrata sheet. The trick is to not cavalierly dismiss a part (or family) simply because it's not perfect, or its architecture isn't your favorite, etc. Picking the right MCU for the job is one of the more complex, and probablyTHEmost significant, aspect of any embedded design. You have to consider the peripherals you need and whether they'll be on-die or external, cost, packages, availability, architecture (which is often driven by language choice), staff familiarity (impacts development time/cost), whether you have to buy new hardware/software tools to use it (and the associated learning curves), etc.And that's just a partial list. The internal architecture is important, yes, but seldom a true deal-killer. It's just one of many factors to consider.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 01, 2022, 04:39:33 pm
content: Quote from: IDEngineer on August 01, 2022, 03:59:19 pmA big danger with errata is using a part you've used before as it's familiar, but not re-reading the errata to see if it affects the new project

author: IDEngineer
author_rank: Super Contributor
timestamp: August 01, 2022, 05:15:17 pm
content: Quote from: mikeselectricstuff on August 01, 2022, 04:39:33 pmAgreed. But that's just part of the evaluation process. Does it have the peripherals needed for this project? Any bugs in the errata that affect this project? And so forth. That's why I said the choice of MCU may be the most significant aspect of an embedded project.

author: voltsandjolts
author_rank: Unknown
timestamp: August 01, 2022, 05:35:03 pm
content: Quote from: mikeselectricstuff on August 01, 2022, 03:56:19 pmNobody?Oh, you mean the folks who don't give a damn about performance, stack depth, linear RAM, interrupt priorities, shadow registers, tail chaining etc, etc. Got it.It's all about the peripherals only when the core is a good modern one.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 01, 2022, 06:58:22 pm
content: Quote from: voltsandjolts on August 01, 2022, 05:35:03 pmOK almost nobodyQuote...only when the core is "good enough" for a particular application, regardless of age.The success of Microchip, and even the 8051 would suggest that these are good enough for a very large range of applications.I'd contend that within a given class of MCUs ( width, clock speeds) , there is very rarely enough differentiation in the core alone to matter to the majority of people compared to peripherals, power and other non-core parameters.

author: David Hess
author_rank: Super Contributor
timestamp: August 01, 2022, 09:16:14 pm
content: Quote from: Berni on August 01, 2022, 09:43:49 amPIC was also one of the first, if not the first, reprogrammable microcontrollers in a plastic package making it incredibly easy to use and inexpensive, starting with the 16C84. Before this developers had to use UV erasable chips in ceramic packages. And the development tools were cheap as well. The 68HC811 might have been second, but being from Motorola had horrible availability, and development costs were much higher.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 01, 2022, 09:28:50 pm
content: Quote from: David Hess on August 01, 2022, 09:16:14 pmThere were a few others, like the Philips 87C751(?) which was 28-pin single-chip OTP device that wasn't very expensive, and a few other OTP 8051 variants, but the PIC16C54 etc. were undoubtedly the first devices to target OTP for production in place of mask rom.

author: nctnico
author_rank: Super Contributor
timestamp: August 01, 2022, 09:50:23 pm
content: Quote from: mikeselectricstuff on August 01, 2022, 06:58:22 pmIn the 80's yes. You have to factor in that microcontroller firmware (and software) has become a lot more complex with all kinds of communication protocols. 8015 and the lower end PICs are great to program in assembly but horrible to compile C for (let alone C++). On these kind of CPUs you can only use a subset of the C language as these cores do not support use of pointers properly. This makes porting code between platforms very complicated because code tailored for PIC or 8051 will work sub-optimal on other platforms and vice-versa. Technology has advanced and the CPU cores used in the 8051 and lower end PICs are horribly outdated nowadays.

author: brucehoult
author_rank: Super Contributor
timestamp: August 02, 2022, 01:48:06 am
content: Quote from: nctnico on August 01, 2022, 09:50:23 pmThey both have some kind of indirect register thingie (DPTR, FSR/INDF). At least in the models that have at least 256 bytes of RAM rather than 32 or something. Do you need C if there is less than 256 bytes of RAM?On many CPUs with less than ideal instruction sets some kind of optimum can be found where code that needs to be fast is written in assembly language but 99% of the code is written in some more convenient to use and more compact instruction set (often referred to as "bytecode", though it isn't always) that is then interpreted.The interpretation was often about 10 times slower than native instructions (which is a lot better than BASIC or modern Python), but the code could often be 2-10 times smaller than native code, so even after allowing for the size of the interpreter you could quickly be ahead on total code size.One well known example is Steve Wozniak's SWEET16 for the Apple ][. The interpreter was about 300 bytes of code. It used 16 pairs of zero page locations to provide 16 pseudo 16 bit registers and instructions to do arithmetic on them and use them as pointers etc. Register 0 was used as an accumulator. To do "r3 = r4 + r5" (a 16 bit add) you would code 0x24 0xA5 0x33 (LD r4; ADD r5; ST r3). It would take 13 bytes of native 6502 code to do the same add on the same memory locations.Are similar things used in PIC or 8051 land?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 02, 2022, 02:05:36 am
content: Quote from: mikeselectricstuff on August 01, 2022, 06:58:22 pmFor example, I did the HW/SW to a little handheld device recently. A few pushbuttons, LEDs, etc., you can change rate/intensity of the mechanical function among a few presets, and, that's about it. BMS/charger, and MCU with power-down state. Pretty much anything would do, but a pure software solution (plus GPIOs say) would need... well, not sure, as far as bit-banging the LEDs, which I did as a dimmable matrix. Maybe some 10s of MIPS if pure CPU. Needless to say, just one timer helps out greatly with that. I also used ADC to compensate for Vbatt, and another timer to PWM the mechanicals.Almost anything has that set of features available, so, aside from size, probably most 80s MCUs even could've done that. I went with AVR, because of course, and ran at all of 4MHz. Plenty of CPU cycles to spare (plain C, no particular effort spent on optimization). Any dank old PIC or 8051 can do that. Well, I did need a couple multiplies (compensate for Vbatt), which maybe an 8051 wouldn't be able to do fast enough to reduce flicker. But one with hardware multiply would likely be fine.Whereas, sometimes you have piddly little applications like this, but they need communications instead: I2C, SPI, USART, CAN, IrDA... Some to talk with external peripherals, some for direct communication, some just to generate relevant waveforms (like using SPI to generate WS2812 pulses, or IrDA, SPI, USART or others for generating remote control signals, radio comms / modem stuff, etc.). Or maybe you don't even need a timer (or many), or ADC, etc., but you're using up every single one of the six USARTs provided...Another recentish project used AVR-DA's TCD as very much a core element; this could probably be handled by a bit of external logic with more traditional / basic timers, but having all the features integrated not only reduces external hardware but reduces CPU responsibility as well (the fault disable mechanism, routed via event system, means the CPU can do just whatever in the mean time). Or, put still another way: it reduces a traditional DAQ-hardware system, say CPU+ADC+DAC - TL494, to just MCU. If a minimal chip solution is required, it simply wouldn't be possible without a timer like this, and/or a regular timer with EVSYS and CCL.So there's very much value in spamming every possible peripheral that can fit, and letting them do as much work as possible. The CPU needn't be all that important, sometimes it is; or sometimes you can get by with fewer/simpler peripherals thanks to extra CPU power, etc. Although, as CPUs get more complex, so too the peripherals, after all why shouldn't they?Another perspective: look at what's been done on any classic PC or game console. Partly by absolutely heroic ASM coding, but also by eking every last clock cycle of value out of the available peripherals. Raster graphics devices, you see raster bars and other scanline tricks a lot; there's a bias for horizontal banding and movement. But you'll never* see full-screen rotation and scaling on a Sega Genesis, that feature is unique to the contemporary SNES hardware.*There are hacks, like moving around tiles/sprites in software. The blocks themselves don't rotate, but their arrangement does. Which looks alright -- correct, even, at small angles. And, sprites up to a modest size can be blitted directly by the CPU -- thanks to the powerful 68k, something the SNES' pitifully slow 65C816 can't hope to do -- but not enough, I think, to cover the full screen, or while doing more than basic animation on other layers.Or the modern C64/Amiga/etc. scene, people crafting accelerator cards for them for example. Basically plug in an SBC and use the base machine as a graphics terminal. Or, the main CPU is still in control as such, but the amount of power at its proverbial fingertips is as a magic oracle, able to compute whole megabytes in the blink of a scan line. For such an interface, you need to somehow enumerate exactly what operations can be performed (or somehow program them i.e. drop in "microcode" for the accelerator to run), but the number of operations can be extremely large, even for very modest APIs (e.g. 65k different operations from a 16-bit index); and if one does what you're looking for, or the composition of a few operations will get you there -- why not, right?Or for a more realistic example: your boss doesn't need to be smart, as in, able to do every job under them; they just need to be responsible, and understand what those jobs do, how they go together, etc. (Much as we would like them to know better... the fact remains, there are more than enough successful (read: not constantly going bankrupt) companies which fit this pattern, for better or worse.)Tim

author: Kjelt
author_rank: Super Contributor
timestamp: August 02, 2022, 05:17:26 am
content: Quote from: David Hess on August 01, 2022, 09:16:14 pmMotorola 68HC805 was first according to this (see picture)Quote from: mikeselectricstuff on August 01, 2022, 09:28:50 pmThat (OTP) does not count as REprogrammable in my book.Those OTPs were made from the 70s since it were the same dies but in a closed plastick or ceramic package as the UV erasable ones that had a ceramic package with the glass window. The first controllers were all ceramic with glass window and the otp ones had a gold cap soldered over them.Also there were specials the prototyping versions of new microcontrollers. They had a ceramic package and pins on top where the seperate eprom could be inserted.The first microcontrollers used all the die for their core, the rom section did not fit so they already had two dies in a package back then.

author: Berni
author_rank: Super Contributor
timestamp: August 02, 2022, 05:37:32 am
content: Quote from: brucehoult on August 02, 2022, 01:48:06 amUnfortunately yes. The PicAxe or BasicStamp on the PIC. Haven't used those, but i think they ware both dog slow, especially since the Stamp executed the program from external serial memory. Tho it was packaged more as a product in the form of a already programmed OTP PIC chip that included the UART bootloader and everything. They ware essentially the 'Arduinos' of the early days as it was mostly used by hobbyists because of being easier to use.As for C compiler support for the PICs. Id say it is more than good enough. The compilers from the early days indeed rather poor. These days they run on the HiTech C compiler . They got bought by Microchip to become the xc8 compiler and replace there own in house compiler (that was worse), making it the new official vendor compiler. That compiler was designed from the ground up to run on tiny crappy hardware and does a pretty good job at it. It makes compact fast code and supports things like pointers just fine (within reason ofcouse). One still has to be careful when doing fancy math since it loves to cast things to 8 bit whenever it gets the chance (since PIC16/PIC12 suck at math). Sure it won't be like using C on a modern ARM chip, the compiler is not magic, but it gets impressively close given the crappy architecture it has to run on. I have crammed things like PID regulators(including UI) inside about a kilobyte of program memory using C on a PIC.As for C++...No....Just no. Wrong tool. period.The chip was not even designed to run C and is bad at pointers. You also are not going to develop applications big and complex enough to actually benefit from the C++ syntax sugar, hierarchy, modularity...etc. You only have a few kilobytes of program memory to work with anyway. If you are making an application that complex then why are you even looking at a 8bit PIC. Go get a cheep low end ARM chip instead, costs just slightly more and it eats C code for lunch.

author: Colt45
author_rank: Contributor
timestamp: August 02, 2022, 06:30:37 am
content: Quote from: Kjelt on August 02, 2022, 05:17:26 amOld school EPROM is reprogrammable whether you count it or not!

author: Kjelt
author_rank: Super Contributor
timestamp: August 02, 2022, 06:57:03 am
content: Quote from: Colt45 on August 02, 2022, 06:30:37 amOTP = One Time Programmable != Reprogrammable.So the eprom is inside a plastick/ceramic sealed package, good luck reprogramming that one without milling off the top or desoldering the cap.That being said, it was obvious by naming the Microchip PIC16C84 that the point was that it was one of the first chips where you did not have to remove EPROM chips, erase them, program them , reinsert them, to do the reprogramming.That was the turning point for the firmware developers. Before that you had to buy a very expensive large box , usually called ICE (In Circuit Emulator) that had RAM chips instead of ROM and you could debug and program on the fly with it. Those boxes where build by specialized firms like Lauterbach and the likes, needed a PC as host and costings thousands of dollars.That this was no longer needed by using eeprom and later flash inside the microcontroller combined with JTAG debugging etc. , that was the great breakthrough for developers.

author: wraper
author_rank: Unknown
timestamp: August 02, 2022, 07:09:24 am
content: OTP can only be erased with X-ray of carefully selected strength (to erase but not fry) and applied for quite some time.

author: David Hess
author_rank: Super Contributor
timestamp: August 02, 2022, 07:29:52 am
content: Quote from: brucehoult on August 02, 2022, 01:48:06 amYes, the "similar thing" is called a macro assembler, and I took advantage of one on every CPU where I did assembly, including the 6502, 8080, Z80, PIC, and 8086. I used it to do exactly what the SWEET16 interpreter does, but the result is inline code.

author: IDEngineer
author_rank: Super Contributor
timestamp: August 02, 2022, 07:40:45 am
content: Quote from: Kjelt on August 02, 2022, 06:57:03 amAh, the good old days of things like the Intel MDS development system (big blue box). Basically an early Personal Computer. Then you purchased their ICE for the target processor. The complete workstation was $30K back in the 80's when that was real money. We Engineers used to jostle for access to the one or two such workstations in the lab. Lots of late nights.At one of my early employers they had purchased a similar setup from National Semiconductor called StarPlex. I can't remember if National second-sourced the 8048/8049 MCU family, but they did offer the ICE modules for that family and had talked the company into buying one before I arrived. Nobody bothered to learn how to use it so it sat neglected in the corner of the lab. I had one at my previous employer, so when I walked in the door of my new company I basically had a dedicated $30K ICE workstation all to myself! It was awesome. Everyone else still competed for access to the Intel MDS's while I just strolled in and did my work whenever I felt like it. This ticked off the other Engineers, but they were the ones too lazy to learn the StarPlex... they could have spent a day to learn it and then had the same advantage as me.Eventually third parties started offering standalone ICE's that connected to PC's via a serial port. Those overtook the hyper-expensive Intel MDS and National StarPlex because you could buy a $5K PC and a $3-5K ICE instead of a $30K workstation that had less processing power and only did one task. These standalone ICE's remained popular through at least the 80386 era (I remember ICE's being offered for that family). But eventually JTAG and similar on-chip hardware debugging became the norm and ICE's gave way to the sub-$100 debuggers we take for granted today.Those original ICE's were something. Big metal boxes that literally emulated the processor with discrete logic. They were expensive but really FELT expensive too. I don't remember when the first ICE came out that used a specialized version of the die in question but the early years were basically boxes full of discrete DIP packages, often on a stack of several interconnected PCB's. Twisted ribbon cables came out to a 40-pin DIP plug that inserted in place of the MCU in your target PCB. Smart users stacked several 40-pin machined pin sockets on those DIP plugs because it was too expensive to break off a pin from the primary connector. All the stray capacitance and inductance didn't matter because MCU's in those days generally ran at ~10MHz. The seemingly oddball 9.216MHz crystal was in fact quite commonplace because that magic value worked with the dividers in the 8048/8049/8051 family to yield traditional serial baud rates of 300/1200/9600/19200 so you could implement bidirectional serial comms by bit-banging MCU pins. On-chip peripherals were still years in the future.

author: jfiresto
author_rank: Frequent Contributor
timestamp: August 02, 2022, 08:09:19 am
content: Data General had a simpler scheme for their single board computers, where you plugged a stripped down SBC into the development system backplane and used the system's CPU and memory.

author: voltsandjolts
author_rank: Unknown
timestamp: August 02, 2022, 08:32:04 am
content: Quote from: mikeselectricstuff on August 01, 2022, 06:58:22 pmThat's true, but that just means people still use them in 2022 _despite_ the fact they suck!QuoteIn normal times you can get a better core (=more pleasant dev/debug/performance) for the same price as the sucky ones.I'm not just bashing Microchip.I like PIC24 and up. I like their datasheets. Pin compatibility. GCC ports are solid. MPLABX, meh.But the pricing on their low end PIC parts warrants a better core, hell they could put the AVR8 core in them now, winner!

author: nctnico
author_rank: Super Contributor
timestamp: August 02, 2022, 10:33:26 am
content: Quote from: Berni on August 02, 2022, 05:37:32 amWell, the 8051 can address 64kB of program memory and 64kB of RAM. Some extended versions can address even larger amounts of memory. I have worked on (inherited) projects that had quite a bit of memory attached to an 8051 and it sucked big time to program in C.

author: westfw
author_rank: Super Contributor
timestamp: August 02, 2022, 10:43:16 am
content: QuoteThe thing is, this isn’t exactly true. There are just as many trivial embedded applications as there ever were, that you can do on a pic16 with 1k words of memory, and no compiler.It would be a big mistake to think that that means the pic16 chips are the only ones you’ll ever need to buy, or that you’ll never need to learn to program in anything but pic16 asm, but that doesn’t mean that the “reasonable uses” has “gone away.”

author: Kjelt
author_rank: Super Contributor
timestamp: August 02, 2022, 10:57:33 am
content: Quote from: westfw on August 02, 2022, 10:43:16 amI think he means the abundant excessive large peripherals.Nowadays a single timer peripheral in an STM32 takes up more pages in the reference manual than the entire manual for the 8048

author: brucehoult
author_rank: Super Contributor
timestamp: August 02, 2022, 11:02:42 am
content: Quote from: David Hess on August 02, 2022, 07:29:52 amIf it makes inline code then it is NOT the same thing at all. It is the opposite of the same thing.The ENTIRE POINT is to fit the maximum amount of application logic into a given sized ROM or RAM compared to hand-written code.

author: nctnico
author_rank: Super Contributor
timestamp: August 02, 2022, 11:21:01 am
content: Quote from: westfw on August 02, 2022, 10:43:16 amNowadays you can buy ARM based microcontrollers in all sizes. For example: NXP has these from 8 pins to hundreds of pins and all with peripherals that are similar so you only need to learn 1 architecture and set of peripherals to cover an enormous wide range of applications with maximum code re-useability.

author: Berni
author_rank: Super Contributor
timestamp: August 02, 2022, 11:29:55 am
content: Quote from: nctnico on August 02, 2022, 10:33:26 amYou can have up to 2MB of external data or code memory on a PIC18F. But the clumsy ways of addressing probably makes it barely useful. The 8051 is probably better at it but still wont elegantly handle large amounts of memory.If you have an application that needs these large amounts of memory then one should also use a CPU that knows how to use it properly. Usually this means a 16 or 32 bit CPU so that you can throw pointers around just like any variable. The modern ARM chips are cheep these says and have C++ support that is beat only by x86, no problem addressing 4GB of memory.But in general pointers are often not quite as necessary in programing as people think. A lot of stuff can be done perfectly fine without them and is often done so in assembler. But in C it tends to be easier to just use pointers for everything.

author: nctnico
author_rank: Super Contributor
timestamp: August 02, 2022, 11:35:16 am
content: Quote from: Berni on August 02, 2022, 11:29:55 amThat is true but try convincing people that are stuck in the 8051 (or PIC) world that there are better solutions out there. The project I mentioned would have been much better off using a H8/300H series microcontroller from Renesas for example.

author: Kjelt
author_rank: Super Contributor
timestamp: August 02, 2022, 01:53:34 pm
content: Quote from: nctnico on August 02, 2022, 11:21:01 amST has the same but what I really DO miss is flexibility.For instance (just an example) the die is always the same so the chip has for instance 5 timers.Then ST chooses for example that the 32 pin version only gets TIM1,2 and 4 and to what pins, the 100 pin version for instance does have all 5 timers.What I really would like to see is that the customer can program the chip which peripherals to which outputs/inputs pins are routed.Just a very tiny small piece of glue logic that you can program through Swim.So that the customer if he wants 5 timers but for instance no second UART etc. can choose that also on the 32 pin version.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: August 02, 2022, 02:26:37 pm
content: Quote from: benSTmax on July 30, 2022, 09:48:09 amI fell down the same hole, pcb's designed and bought only to find USB didnt work.Had to rework circuit and pcb for a 100 pin device.I have used PIC's since 1985 and worked for a PIC Consultancy for 13 years.Didnt have too many problems but hated the PIC assembly language.Was happier once C compilers came online.A customer decided to use PIC's so wrote code for it.Customer bought in a first batch 100 PIC's.In their wisdom they soldered them all in without programming them !So muggins here had to desolder them, program them then resolder them.

author: free_electron
author_rank: Super Contributor
timestamp: August 02, 2022, 02:56:45 pm
content: Quote from: IDEngineer on August 02, 2022, 07:40:45 amMDS and the Intellec ( the white machine , 8086 based, ran ISIS as operating system. ) and the PDS : a portable..I used MDS for 8051 and 8096 and Intellec IV for the i960. we made several multibus board for the Intellec to hook up to the telephone exchange. Those were the days of ISDN ... The intellec had a door on the right hand side so you could easily plug in new boards. Lift cover, plug in board and go. The Alcatel system 12 exchange ran on i960 processors for the ADSL boards. the first ADSL modem (T1000) also ran on an i960.i worked on the two chips top right :the large one was the digital processor and did all the signal processing and brought out ATM. The smaller one under the crystal is the A/D D/A. We did not have the ability to drive the line directly. that came only later. Initially used AD815 or Tripath drivers. Part of the analog frontend was also not integrated in the A/D D/A , it needed DG309 analog muxes and external filters with AD811 opamps.We switched to Arm 7TDMI and later the CARM (cached arm) I made the first board with the CARM

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 02, 2022, 03:16:24 pm
content: Quote from: Kjelt on August 02, 2022, 05:17:26 amIMO the jump from maskrom to OTP was probably the biggest change in MCUs, as it slashed entry costs enormously and opened up whole new application areas.Reprogrammability was obviously nice to have for development, but less of a game-changer, especially before self-programming became a thing, to allow updates via existing interfaces.

author: free_electron
author_rank: Super Contributor
timestamp: August 02, 2022, 03:35:53 pm
content: Quote from: mikeselectricstuff on August 02, 2022, 03:16:24 pmAnd that gave rise to the current software methodology : ship now, fix it in an update later. In the "good old" days of mask rom you had to really test the thing before committing to the mask build. Now its a gigabyte of flash full of warts.

author: Kjelt
author_rank: Super Contributor
timestamp: August 02, 2022, 03:57:05 pm
content: Quote from: free_electron on August 02, 2022, 03:35:53 pmTrue but remember those good old days that testing a simple crt Philips tv would take 7 months, eg the product cycle was two years which meant two seperate teams in parallel to be able to deliver a new product each year.With the current firmware and software in tv's a full test cycle would mean years of testing each and every feature and since new apps arrive each week you would never be finished

author: Berni
author_rank: Super Contributor
timestamp: August 02, 2022, 04:43:32 pm
content: Quote from: free_electron on August 02, 2022, 02:56:45 pmNot related to the conversation, but dang is that a tidy looking PCB. Can clearly see a whole lot of love went into the layout.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 02, 2022, 05:46:39 pm
content: Quote from: Kjelt on August 02, 2022, 01:53:34 pmMost PICs have that facility nowadays, even the 8 bit ones.

author: benSTmax
author_rank: Regular Contributor
timestamp: August 02, 2022, 06:13:42 pm
content: Quote from: mikeselectricstuff on August 02, 2022, 05:46:39 pmIndeed, PPS in PICs is a life-saver. Microchip SAMs and AVRs should have it too

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 02, 2022, 07:22:56 pm
content: AVRs have limited remapping; since XMEGA, peripherals have been port-associated, e.g. USART1 appears on PORTC, but you can choose which nibble the TXD/RXD/XCK pins appear on. AVR-DA is somewhat more advanced, with limited mux options for some peripherals; USARTs are mostly stuck where they are (but there's enough of them you mostly don't care), but others have a bit more range, like SPI, timers, etc. may have 2-3 choices each, with a few exceptional cases having many (TCA, TCD most prominently). And other things like the EVOUTs and CCL LUTs, you can likely shuffle around to get the pins you need.I actually availed myself of this on said recent handheld thingy project; originally the motors were going to be fixed on/off, then we decided to run PWM on them. The pins I picked for them, weren't on any timer remap list, but happened to have an EVOUT and a LUT respectively. So, used EVSYS to reroute one timer, and EVSYS into CCL.LUTn to reroute the other.EVSYS and CCL (or PPS or whatever else they want to call it) is a more precious resource than a full peripheral mux/matrix, so you might not be able to make a whole lot of use of this, but it's nice to have as an option, and there you go, saving on board revision just like that.If they are indeed going to fine-pitch / high density cores, it may well be feasible to put in yet-more-ornate muxes like that (even in the larger i.e. 100+ pin devices).Tim

author: free_electron
author_rank: Super Contributor
timestamp: August 02, 2022, 09:08:34 pm
content: Quote from: Berni on August 02, 2022, 04:43:32 pm6 layers. the advantage of making your own asics is you can chose the pinout. a lot of work went in to doing a layout with as few vias as possible. based on the ram and the i960 pinout we did the ASIC pinout.Then again, these are not "consumer" products, so they have a bit more wiggle room when it comes to price-point

author: David Hess
author_rank: Super Contributor
timestamp: August 02, 2022, 10:05:47 pm
content: Quote from: mikeselectricstuff on August 02, 2022, 03:16:24 pmIt was a huge change. The problem now is that floating gate memory is only available down to 28 nanometers, so OTP processors can only be produced on legacy processes.

author: westfw
author_rank: Super Contributor
timestamp: August 02, 2022, 11:54:14 pm
content: QuoteBut can't they produce OTP chips using Flash technology and leaving out the charge-pumps/etc needed to erase them? I thought there were a substantial number of such chips, actually.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 03, 2022, 12:10:45 am
content: While 28nm is certainly old stuff already for the CPU market, most "MCUs" out there tend to be fab'ed on older processes still, and any MCU on a 28nm process is already pretty advanced shit these days.

author: IDEngineer
author_rank: Super Contributor
timestamp: August 03, 2022, 01:06:15 am
content: I have no data to support this, but I bet the IC fab market is like most other markets. Some stuff at the bleeding edge (small feature sizes), some stuff still way back on big nodes, and the vast majority of chips being fabbed on middle-of-the-road nodes/processes. I bet the fab industry produces several orders of magnitude more MCU's every year than Intel/AMD's latest bleeding edge CPU's even though the latter get most of the press coverage and fanbois attention. Cars these days have dozens of "processors" (example: everything that connects to CAN) but nary a single i9 anywhere. And that's just one market.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 03, 2022, 01:45:22 am
content: Keep in mind power consumption, especially in low-power modes (sleep/stop/...) is a key point for MCUs these days, and due to usually higher leakage on finer process nodes, MCUs on the finer nodes are usually not that practical. Except possibly for the top-end of what is considered a MCU at the moment, such as the Cortex-M7-based ones, in particular like the NXP iMXRT series. And from what I remember, even those are on a 45 nm process at the moment.

author: David Hess
author_rank: Super Contributor
timestamp: August 03, 2022, 01:57:33 am
content: Quote from: westfw on August 02, 2022, 11:54:14 pmThat *is* NOR Flash. It does not scale below 28 nanometers because retention is too short.

author: Berni
author_rank: Super Contributor
timestamp: August 03, 2022, 05:25:26 am
content: With very simple MCUs you don't really gain much from going to the smaller processes. They do still need bonding pads that can't just shrink along. Using an old fab node is also a good way of saving money because the fab that is now obsolete for making the bleeding edge chips is still more than good enough for making MCUs.This is also where the chip shortage hit the hardest. There is only a certain number of these low tech fabs around that can make things like MCUs. The bleeding edge fabs that do <8nm produce x86 CPUs, GPUs, Phone SoCs etc... ware mostly kept busy by the crypto mining boom, but now that mining fell over they have extra capacity that they don't know what to do with, but can't be used to make the low tech chips that we need. For example the Raspberry foundation pushed out a ComputeModule 4 redesigned to fit into the CM3 form factor because the SoCs for the Pi3 are on a particularly busy process node while the Pi4 CPUs are on a smaller more modern node where they have a bit more capacity, so it is used as a workaround to help costumers who designed the CM3 into there design and are not stuck unable to ship products.

author: hans
author_rank: Super Contributor
timestamp: August 03, 2022, 06:56:28 am
content: STM32H7 is on ST's 40nm:https://en.wikipedia.org/wiki/STM32#STM32_H7But the F4, F7 is at 90nm, which was first introduced 20 years ago. I guess it will take a while before we see 28nm or much lower commonly, although in high-end I'm sure you do see it first.With small process node you will lose certain nice features. I think EEPROM cells are probably the first to get booted, which already has on most MCUs. Then at some point is also a low static power consumption. You can more or less see this with some SiliconLabs low-power MCUs. Even though their new generation has all the bells and whistles for a low operating current (DC/DC, low Vcore, low Icore), the consumption in sleep with a fixed size block (say 8 or 16kB) kept non-volatile is going up from <0.5-1uA to >2uA. For applications where a device has a tiny duty cycle, it makes no sense at all to use those MCUs..

author: Kjelt
author_rank: Super Contributor
timestamp: August 03, 2022, 07:08:36 am
content: Quote from: Berni on August 03, 2022, 05:25:26 amThe story is a bit different.To make a chip or better a wafer with low nm technology you need the extremely expensive high end machines (EUV) with extremely expensive reticles but only for the first layers.All layers above those first layers , there the "cheaper" DUV machines that also can handle the higher nm processes take over to do the top layers like the interconnects to the top pads, power etc.So if you make a low nm wafer your are also occupying the machines that would be perfect to create the cheaper chips.Besides that the lower nm chips earn much more money per hour than the lower end chips. Many fabs don't do the jellybean parts anymore, only the older never updated fablines do those and that capacity is steady.Also the latest chips use many more layers (think more than hundred) that means each wafer has to be processed (coated, exposed, etched, cleaned, coated, etc.) more than hundred times, which is increasing the time for one wafer to be ready (not to mention if anything goes wrong in between like polution or calibration errors or whatever will forego the entire batch).

author: free_electron
author_rank: Super Contributor
timestamp: August 03, 2022, 02:12:03 pm
content: it's even more complicated than what Kjelt wrote. The functions that you seek may simply not be present in those deep technologies. 3.3 volt or 5 volt on 8nm ? forget it. you'll fry the gates. that stuff is made for 0.9 or 1.1 volt max. some devices (like the GPU's) have on-board switchers to lower the voltage even more ( down to 0.65 volt. ). transistors at those geometries are "leaky" . besides : the higher voltage swing they need to do when transitioning from 1 to 0 or 0 to 1 the more power they burn. Every time you are charging/discharging a capacitor. it may be very small but when you have a couple of billion... it adds up quickly.and doing stuff like a/d d/a , comparators, opamps or anything that smells remotely analog .... can't do it. You can technically, but not economically. The structures are so large that you waste area on a simple opamp that could occupy the entire CPU core. So why you need that 8nm then ? you are better off ditching that opamp , putting another core on that wafer and make money selling that extra core.The deep nanometer technologies are for digital stuff.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: August 03, 2022, 07:00:55 pm
content: Quote from: IDEngineer on August 02, 2022, 07:40:45 amAn intel applications engineer (mid 80's) claimed that the division that produced those blue boxes was the most profitable in Intel with respect to net revenue over expenses. He said it was called the metal folding division internally -because boxes! He dropped that tid-bit to us after we complained about the cost and just laughed. At 40k canuk buck$s the management continually pestered us "why do you need this thing?" even after we bought one.

author: benSTmax
author_rank: Regular Contributor
timestamp: August 04, 2022, 06:03:14 am
content: Quote from: Kjelt on August 02, 2022, 01:53:34 pmBesides this very nice idea, I would add we also need improved peripherals.I explored a couple of years ago accessing a 2nd micro through SWD using another micro on the same board.Of course, implementing SWD can be done through bit banging but it could have been done using SPI if the main micro would have supported other transfer lengths than 8 bits or multiples.From the micros I played with, only Pico, NXP/Freescale and TI ARM microcontrollers were able to transfer data between 4 to 16 bits.

author: Berni
author_rank: Super Contributor
timestamp: August 04, 2022, 06:28:03 am
content: Yep peripherals quite often are bloated with useless features while missing very useful features.SPI only able to do 8bit or 16bit is a common one. For example there are also a lot of SPI LCDs that use 9bit SPI (8bit data 1bit command/data flag). Only way around it on those is indeed to just bitbang it.There is also things like I2C peripherals that for some reason love to lock up on many MCUs. There implementation usually makes them unusable for DMA too (Often useful for slow peripherals where waiting for the data takes too long). Then on modern MCus there are peripherals that ONLY perform at full speed using DMA (STM i am looking at you). Where the peripheral has only 1 byte of internal buffer and the flags are so vague or buggy about the buffer state, that the only safe way to refill it is to wait for it to actually go empty before feeding in new data. So the solution is to set up a DMA to spoon feed the peripheral while you wait in a while loop for it to finish, all because you wanted to send 8 bytes out of a SPI port at 30MHz without pauses in the transfer, yet you spend half of that time setting up a DMA

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 04, 2022, 08:16:19 am
content: totally agree about inflexible SPI lengths. I once used the SPI on an NXP part to add an additional TX UART for DMX...and don't get me started about compare peripherals with no output polarity control. I spent ages trying to get a PIC32MX170 to produce precise-length low-going pulses before giving up and adding an external inverter.Fortunately later parts have the configurable logic cell peripheral that can do the inversion.

author: benSTmax
author_rank: Regular Contributor
timestamp: August 04, 2022, 08:55:40 am
content: Quote from: mikeselectricstuff on August 04, 2022, 08:16:19 amI couldn't agree more. Polarity control should be part of all the digital peripherals in a micro.It only takes a very small fraction of the silicon real-estate, however the overall benefits outweigh the slightly increased digital size. AFAIK the analog and pads take quite a bit of real-estate in lower node technologies used for making mid-range to high-end micros.Hopefully, one or more micro vendors will see this thread and maybe incorporate some of our wishes in their next micros.

author: David Hess
author_rank: Super Contributor
timestamp: August 04, 2022, 09:33:22 am
content: Quote from: chickenHeadKnob on August 03, 2022, 07:00:55 pmThey were under-powered and more expensive than contemporary S-100 microcomputers which could run CP/M. Even when we used one, we had a separate Prolog PROM programmer to use with it.

author: IDEngineer
author_rank: Super Contributor
timestamp: August 04, 2022, 03:26:15 pm
content: Along with simple things like output polarity and programmable SPI bit lengths, it would be enormously valuable to have I/O peripherals with something more than a single-byte buffer. This would drop interrupt rates in direct proportion to the buffer depth, either allowing faster speeds or lower CPU burden (or some balance between those two). Yes, I know there are some MCU peripherals which have buffers but many do not and the performance impact can be huge, even if all the associated ISR does is move the latest byte in or out of the single register. You still incur the ISR overhead and the subsequent jitter in system timing.

author: nctnico
author_rank: Super Contributor
timestamp: August 04, 2022, 03:30:08 pm
content: Quote from: IDEngineer on August 04, 2022, 03:26:15 pmNowadays you are supposed to use DMA to implement buffering.

author: IDEngineer
author_rank: Super Contributor
timestamp: August 04, 2022, 04:06:39 pm
content: That presumes the device, instead of having a multibyte buffer, instead has full DMA support. I'll accept either but suspect the former is easier to implement on the die.

author: Berni
author_rank: Super Contributor
timestamp: August 04, 2022, 04:42:50 pm
content: Quote from: nctnico on August 04, 2022, 03:30:08 pmYep DMA capability is nice, but it should be there to free up the CPU to do more useful stuff rather than being required to get full bandwidth out of a peripheral.On the STM32F4 series you can't get SPI to run with no pause between bytes by manual polling even if you dedicate 100% of the CPU to it. It has a 1 byte large buffer and the status flags don't clearly tell you exactly when it needs servicing. Because it is bidirectional you have to both fill and empty the buffer, technically you can service the buffer with the next byte while the previous byte is being shifted out/in, but no matter how i would follow the available status flags something would go wrong causing a data over/under run at some point. The only reliable way was to send 1 byte, wait for it to be transferred fully and then give it the next one (This is also how the official HAL driver does it). This results in a small pause from when you find out it is done and feeding it the next byte. Feeding it with DMA works fine tho.But in comparison here is the process for sending in polling mode:1) Init SPI (Turn on clocks, set register, enable peripheral)2) Write/read data into data register3) Wait for space in buffer4) Repeat step 2 until doneHere is what you do with DMA mode:1) Init SPI (Turn on clocks, set register, enable peripheral)2) Init DMA (Turn on clocks, figure out what DMA channel is able to service SPI, move away other DMA channels in conflict, link up the DMA channel with the correct pripheral, write down the channel so you can use it later)3) Copy data into an area of RAM that is accessible by DMA4) Flush CPU data cache to make sure it is written out there7) Make sure DMA is idle for a new job5) Configure SPI peripheral for a DMA mode transfer6) Configure the DMA with the apropriate address and data size7) Start the DMA transfer8 ) Poll DMA register to check if done, repeat 8 otherwise9) Terminate DMA transfer10) Flush CPU data cache again11) Retrieve received data from the RAM area.Okay sure you can skip the cache flush if you configure the memory management unit to forbid caching that area, but that is even more setup work. Also yes you could do other stuff while the DMA is processing but if i am sending 8 bytes trough SPI at 30Mbit that takes only 2us, what useful stuff am i going to do in that time? If i decide to jump into a ISR in that time that will take 1us for the context switch alone, so we might as well just run in circles in a loop during that time.Why do i have problems like this on a modern 32bit ARM MCU when i never had problems like that on a 16bit PIC way back. It did also have DMA but you could always make peripherals go full speed with polling, the DMA was only there when you needed to send a huge pile of data and you had something useful to do in that time. Then you have peripherals like I2C that are horendusly slow and could use DMA, yet need constant CPU intervention to actually complete a transfer, so the DMA is only usable once you already completed half the transfer with polling.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 04, 2022, 06:20:48 pm
content: Quote from: mikeselectricstuff on August 04, 2022, 08:16:19 amThe Infineon XMC series can do SPI at any data length between 1 and 63 bits.

author: benSTmax
author_rank: Regular Contributor
timestamp: August 04, 2022, 08:32:27 pm
content: Quote from: Sal Ammoniac on August 04, 2022, 06:20:48 pmThanks for pointing this out. I checked the XMC's USIC peripheral and it seems like a pretty versatile one. I will definitely keep the USIC and the XMC series in mind when I will need a more capable SPI/UART/IIS

author: analityk
author_rank: Regular Contributor
timestamp: August 05, 2022, 12:19:05 am
content: Did someone ever used PS4?In my opinion, if you have to use dedicated software to create project (especially pinout configuration) it should be ommited in your mind.Second sad characteristics is code density. I wrote some time ago fast (discrete) Fourier transform on AVR (in C++ if it does matter). Code create testing vector (array) of data using sin(), perform 64 point FFT (on float, not uint16), calculate bin power and throw it into console in formated strings. This all code ocuppy 5026 bytes of flash and 1040 bytes of ram. Try it on your Cortex m0+.Also documetation for uC in Cypress is like a joke.AVR is not cheap if you think about capabilities or MHz but sometimes can make you positive suprise.Cheap is STM8 but you have to use SDCC so it is maby not as bad as it may be but for small volume batch i will take avr.STM is France-Itally firm. But it is more like Fiat than Ferrari. 1000 web location for some serious doc and after this you know you want get manual... It is sad joke.In ATSAM sometime you can meet SSC - serial synchronous controller. It can be preety good - it can generate PCM signals for two I2S codecs workign together on one bus.

author: benSTmax
author_rank: Regular Contributor
timestamp: August 05, 2022, 12:55:57 pm
content: I admire a lot the RPI for what they brought us with the RP2040. It also teached the big micro names a good lesson too.About 10 years or so ago, I remember I saw SGPIO from NXP and I thought it was a nice touch to a mundane peripheral like GPIO. It never took off but at least it showed there is still innovation to be made with a simple peripheral like GPIO.Fast forward some years later, the RPI managed to bring the GPIO innovation to the next level by giving us the amazing PIO.I think the big microcontroller guys should understand they need to bring more disruptive innovation (like the RPI did with their PIO) and stop reusing some of their crappy peripherals over and over again

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 05, 2022, 06:40:13 pm
content: NXP has gone a long way with this with FlexIO in their "newer" MCUs.Some vendors have some kind of programmable logic blocks which can be useful too.The big plus of the RP2040 PIO is that it's both versatile and very easy to use. It takes only a little while to figure out and then you can design fancy custom peripherals. There are dozens if not hundreds of examples all over the place now. While NXP's FlexIO is relatively similar, it's much more complex and I've seen almost no project using FlexIO with the same ease and creativity.All in all, I agree this is something that we are not seeing enough in modern MCUs.

author: hans
author_rank: Super Contributor
timestamp: August 05, 2022, 06:59:21 pm
content: It's pretty disappointing we don't see enough microcontrollers with FPGA-like fabric and powerful MCU together.Such as the previous example about output polarity. Yes you could use one CLC instance, but considering the capabilities per CLC channel (more complex logic on 4 inputs), it's also a bit of a waste too. Output inversion shouldn't be more than 1 flipflop and an XOR gate..But if you have it available, and the alternative is an external logic chip, then the choice is obvious.I wonder, why isn't this an option in the GPIO block? Then those IP devs don't have to scatter around dozens of polarity-invert bits around each peripheral (potentially forgetting to add it on some), but instead, it could be done on a 'global' level.PIO is an interesting alternative approach to a full FPGA fabric. Sometimes you don't need that fine granular flexibility, but still need something 'else'.Then there are plenty of MCUs that are quite imbalanced. Like Gigabit ethernet on a Cortex-m0+ class processor, such as the CH32V307. Or a 10MSPS ADC on a 16MIPS PIC24 (such as the PIC24FJ64GC006). For both, I wonder what the applications of those devices really are... if you can't actually process the data to from/to a high-speed peripheral.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 05, 2022, 07:51:07 pm
content: PIO is sufficiently awesome that it'sbeen implementedin an FPGA in verilog ...

author: westfw
author_rank: Super Contributor
timestamp: August 05, 2022, 11:25:06 pm
content: QuoteThe microcontrollers that HAVE supported things like this have not been very successful. :-(As someone complained at a (Cypress) PSoC seminar I attended: "You want HW engineers and SW engineers to share the same project (files and IDE)??!! Madness!" (ok, somewhat paraphrased.)The built-in options (like PIO or the "Invert" config on rp2040) are more widely accepted.

author: hans
author_rank: Super Contributor
timestamp: August 06, 2022, 07:33:16 am
content: Yes I fully agree. A firmware developer with a computer science background may get overwhelmed with this VHDL/Verilog rubbish. It's more of a hardware design wet dream.And the FPGAs with onboard CPUs are much more capable of running Linux, are also a different order of magnitude complexity for the kind of systems they're involved in.. so the imaginary fence to throw things across is much higher..Now I do see some very talented people in OSS community doing RISC-V+FPGA fabric experiments on ice40/ECP5/etc. , and that are able to make both domains work (like porting Doom to a RISC-V softcore CPU and making memory/graphics/peripherals etc. all work out), but I think you need a solid computer engineering background plus good software skills to pull it off.

author: Berni
author_rank: Super Contributor
timestamp: August 06, 2022, 12:37:17 pm
content: Yeah in my experience the software people really don't like HDL languages. Even just looking at what the language looks like they go "eww". Then the next trap is that once you figure out the odd syntax it starts to look a lot like a weird multitasking C, however trying to use it as such does not end up going well. People who know programing apply regular programing concepts on it that don't work here, or result in HDL code that runs slowly and eats lots of resources. Coupled on top that you can easily just clock your HDL too fast and have it stop working in the weirdest and glicthyest ways (Yes i know timing analysis exists, the new guy wont tho). The more effective way is to write HDL is to imagine what kind of logic functions need to be wired together to do the job, then write that down as HDL. A software developer never worked with 74xx logic, all they know is what a AND,OR,XOR look like because they can do that in software as bitwise operations.Heck even when it comes to drivers you can loose some of the software developers that are used to thinking in more high level terms. For example way back we had a case where the hardware engineer connected a MPU interface LCD to the external memory controller on a ARM MCU, some time later a software developer comes back in furious as to why the data bus was jumbled up across 3 different GPIO banks, he would have to do so much bit shuffling to actually get data on them. Only to be informed that the LCD data bus was wired up like that so that it would appear in the memory map and let him DMA straight into it.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 06, 2022, 01:02:58 pm
content: Quote from: Berni on August 06, 2022, 12:37:17 pmThe problem is HDL looks on the surface like software, but is a completely different concept

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 06, 2022, 05:48:10 pm
content: Quote from: Berni on August 06, 2022, 12:37:17 pmThe best way to avoid issues like that is for the software team to work with the hardware team during board definition. Sadly, too many teams fail to do that and it results in designs that the software team has to jump through hoops to get around, or doesn’t understand why something was implemented in the manner it was (as in the case described above).

author: Bassman59
author_rank: Super Contributor
timestamp: August 06, 2022, 06:37:13 pm
content: Quote from: Sal Ammoniac on August 06, 2022, 05:48:10 pmThe converse of that is when the hardware engineers have to jump through hoops to implement something in a weird way because the software team defined something and can't/won't change it.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 06, 2022, 06:42:08 pm
content: Embedded software developers who don't understand hardware should not be trusted IMHO anyway.But hardware engineers who don't understand software shouldn't either for embedded development.Tough shit.Then there are the (very) few who are equally not too bad at both.

author: Berni
author_rank: Super Contributor
timestamp: August 06, 2022, 09:05:26 pm
content: Yeah not always are the right people in on making decisions. Sometimes there is just a brain flash of a product idea of something to be made, there is no software guy assigned to it yet, but the brilliant idea gets dropped off in the hardware department so that work on it can begin ASAP, sometimes with too much hurry to even set down some solid performance targets. Then perhaps a rough prototype is build and handed over, but then a lot of code ends up developed for the prototype and then the final product has to be very close to what the prototype was since otherwise a lot of code has to be rewritten, so a quick and dirty solution to something might now be a mandatory feature in it...etc Most likely the same thing will also have to be in another similar product because they already have code to do it.But it is clear that whenever dealing with embedded systems you need a bit of cross discipline knowledge on both sides. The programmer better have an idea of how the hardware works and at least what a pullup resistor looks like and how to read schematics. On the other hand the hardware engineer should have some insight into how the software plans to run the product so that the hardware can be designed in a way that makes doing those tasks easy.But the one thing i have learned is that software developers will always want the most powerful over the top hardware possible. They appear to need 200MHz and 64KB of RAM to do the most basic of things these days.

author: nctnico
author_rank: Super Contributor
timestamp: August 06, 2022, 09:20:57 pm
content: Quote from: Berni on August 06, 2022, 12:37:17 pmNo. For HDL development you need an HDL engineer. That is somebody who knows how to apply a software development oriented workflow to programmable logic / ASIC development. If you let a software engineer or hardware engineer write HDL, you'll get unmaintainable rubbish with very long development times.To make a comparison: The software engineer will try to use Java and the hardware engineer will use assembly while the right tool for the job is C.

author: Kjelt
author_rank: Super Contributor
timestamp: August 06, 2022, 09:36:26 pm
content: Quote from: Berni on August 06, 2022, 09:05:26 pmThat is just as BS as saying that HW engineers want 12 layer boards so they don't have to sweat when laying out the traces.The unfortunate thing seperating HW from SW is requirements and product features that say are frozen for hardware at start time 0+1 year.Then the board is finished tested and done.With SW the initial requirements should also be frozen at that time.Then you can get an optimized design.But for SW nothing is frozen*.After testing or releasing the product, customers or company engineers find new features thus changing requirements and having witnessed many products myself from birth to maturity this could have a huge impact.Product A from 2011: initial product hardware M3 128kB ROM 64kB RAM.Used at release v1.0: 98kB ROM 42kB RAM.2016: v3.24 124kB ROM 64kB RAM and having some new features rejected due to HW limitations. Plus aprox. 14 manmonths "waisted" on optimizing code, rewriting some parts to be able to release v3.x because it did not fit.We even had an issue that for debugging we already ran out of space in 2012 so we put a bigger chip with unfortunately a different package to a conversion board for debugging.The reason we were not allowed to use a bigger chip at release was because it was not needed and it was $0.90 more expensive. Sales predicted 6M pcs in 8 years so that would be a loss of $5.4M.Now I totally agree that if there is no need to use an very large chip you shouldn't do that but make sure you got enough space to expand when the feature list expands over time or convince mgt to release a new product, actually then putting up a middlefinger to the first group of customers.*in case of firmware update possibility that is.

author: IDEngineer
author_rank: Super Contributor
timestamp: August 06, 2022, 10:23:10 pm
content: Quote from: SiliconWizard on August 06, 2022, 06:42:08 pmI've long told my son, who is working on his EE at CalPoly, that the best Engineers are those who understand BOTH hardware and software. Such people understand the tradeoffs of both and can most accurately choose where the dividing line should be between hardware and software. The folks who only know one discipline can create some laughably stupid results.Like the pure software guy who once insisted a design needed to add an A/D for input, and a D/A for output, so they could apply fixed gain to an analog signal in firmware. Honestly he didn't really understand converters, he just thought of them as "black boxes" that gave his code access to the real world. In my best stage whisper I said "You can do that for twenty five cents with an opamp and a few discretes". He gave me this look of pity, like I didn't really understand the problem. In the end the analog hardware solution was almost free because there was a spare opamp available in a dual or quad package that was already on the board.My story is I started in analog hardware, then digital hardware, then microprocessors, which led to Assembly language, which led to systems architecture, which led to C/C++ and a smattering of other languages. I'm very comfortable with everything and constantly think about the interdisciplinary tradeoffs. And I still automatically worry about clock cycle count, having come from the days when single digit MHz clocks were considered "fast" and every cycle mattered.

author: brucehoult
author_rank: Super Contributor
timestamp: August 06, 2022, 11:35:21 pm
content: Quote from: mikeselectricstuff on August 06, 2022, 01:02:58 pmI disagree with that. There are many different kinds of "software".HDL is a programming language that builds a flow graph.There is plenty of other software that does the same thing. Compiler optimisers and back-ends, for example.Modern compilers are manipulating the flow graph to a shape that is wide (has as many live values) as possible -- at least if possible up to the decode/execute width of the CPU back end, and at most up to the number of registers in the CPU.This is the same basic task of organising a hardware flow graph into stages with each stage taking values from physical registers (flip-flops), doing combinatorial logic that is as wide as possible but not deep, and going back into registers for the next clock cycle to start from. Or maybe sometimes you want to minimise the number of live values (register bits). In any case you're manipulating the shape of a flow graph.These things are SO SIMILAR that there is a project called CIRCT that uses the LLVM compiler infrastructure to optimise hardware. The Chisel -> FIRRTL -> Verilog workflow does the same kind of thing, with FIRRTL -> FIRRTL transformations to optimise the flow diagram in various ways.This is very different to business software programming, or web site development using Javascript, certainly.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 07, 2022, 12:13:33 am
content: Agree with Bruce there.What most people mean when saying that HDLs are not "software" is that they are notimperativeprogramming languages, which is what most people are still familiar with.Yes, HDLs describe "structures" and not a direct sequence of operations, but so do many programming languages with paradigms different from imperative. A pure functional language for instance. So yes, a series of statements in HDLs is *not* a sequence, but we can say the same for many other programming paradigms, with which I'm sure many people would struggle just as much.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 07, 2022, 05:59:43 am
content: Quote from: SiliconWizard on August 07, 2022, 12:13:33 amBut, finally, even imperative language like C, and HDL like VHDL share a lot. In C abstract machine, order of instructions is something comparable to just arithmetic operation precedence. Compiler does not replicate the imperative sequence 1:1, but reads the code and implements something which produces the correct results.Compare this to something under theprocesskeyword in VHDL: exactly the same thing, the language is imperative, compiler (that of synthesizer or simulator) follows the order of "instructions" to figure out which the correct result must be, and then implements the logic in whatever way is most efficient.While it is possible to explicitly write logic gates in VHDL, no one does that, and just instantiating a bare flipflop is so much boilerplate it makes no sense. So VHDL is pretty much written "like software", and even more, pretty much like an imperative language such as C (especially ifVHDL variablesare used).

author: hans
author_rank: Super Contributor
timestamp: August 07, 2022, 07:37:59 am
content: Logic fabrics map very well to functional programming languages like Haskell. If you come from a C or other imperative language background, then Haskell is a huge brainf*k to start out with, but so can HDLs be..I think the difference is that HDLs try to do both. You have combinational logic and process, while IMO a process is such a weird beast. It's one of the easiest way to have logic area explode on you because logic functions may all be naively implemented in parallel, perhaps with duplicates.. You really need to think graphically and get a feeling of where area/time/power bottlenecks may come from.Say you have this piece of code:Code:difference_calculation: process(clk, rst) beginif rst='1' and clk'event thenif calculation_selector = '1' thenoutput_data <= input_b - input_a;elseoutput_data <= input_a - input_b;end if;end process;How is the synthesizer going to implement this? Is it going to have 2 subtractors with muxed output data? (most likely) Is it going to make an area trade-off in which it could apply 'retiming' to shove the mux through the inputs and synthesize only 1 subtractor? (unlikely)If you want 1 subtractor, you will most likely to explicitly implement that:Code:difference_calculation: process(clk, rst)variable sel_a : std_logic_vector(7 downto 0);variable sel_b : std_logic_vector(7 downto 0);beginif rst='1' and clk'event thenif calculation_selector = '1' thensel_a := input_b;sel_b := input_a;elsesel_a := input_a;sel_b := input_b;end if;output_data <= sel_a - sel_b;end process;Or use combinational logic outside the process if you dislike the variable.There is a good reason why you must be so explicit in HDL, because both examples will not behave the same at all. Not just from an area aspect, but also power due to switching activity from propagation delays and combinational logic. In order to optimize properly, you would need to know how often input_a, input_b or calculation_selector changes. If calculation_selector changes (a lot) more often than input_a/b, and power is important, then I would probably choose the first implementation because it has less spurious switching activity.

author: Berni
author_rank: Super Contributor
timestamp: August 07, 2022, 09:13:31 am
content: Yes HDL languages are still programing languages but the big difference is that the end result of compiled code is a logic circuit, not a sequence of instructions.Main point of a HDL language is to save you from having to do everything with logic gates. You can describe your intent using better readable structured code, then the language figures out a way to actually implement it. But in the end it all becomes logic again. Some seemingly simple things in code are actually very tough to implement in logic, so a single line of HDL code could actually cause a giant pile of logic to be placed into the final result that takes up a lot of valuable FPGA fabric space and might run really slow too.This is especially important because in FPGAs the tradeoff between size and speed can be enormous. In a CPU you have a certain number of registers available and you want to use most of them, then they get reused for other tasks anyway. But in a FPGA most the circuitry you put down is dedicated to doing only a single task and there is no limit to how much resources you can dedicate to a single task. So if you need to add up an array of 512 numbers in 32bit you could run them 1 by 1 trough a 32bit adder and take 512 clock cycles to do it, or alternatively make 512 adders and do the calculation in 1 clock cycle. Similar decisions have to be made inside HDL compilers, yet not all of your logic should be optimized for purely speed or for space. So as a result you have to be a lot more aware of what you want the final output to look like. This is why i often tend to look at the synthesized output of my HDL code to see if i agree with what the compiler decided to do. If it got the wrong idea i might change the code around a bit to be more specific about the way i want it done.When it comes to complex HDL designs like processors you definitely want professional specialized HDL designers. But when it comes to simple things like making some glue logic or a simple video format converter or something, you can in most cases teach a digital engineer to be good enough in HDL in a few days.Quote from: Kjelt on August 06, 2022, 09:36:26 pmWell yes some modern products are complex to a point where they need some some large complex code to do what they do, or perhaps they are doing a job where there is no way around lots of horsepower such as driving a high resolution display.I am talking more about simple applications where it doesn't actually have to do much. Things like reading 4 analog voltages and 2 digital inputs and sending it over CAN. Or read some MEMS IMU sensor values and send them over RS485. Or a battery monitor that calculates the SOC from current and voltage and makes that available on CAN etc... All of this are examples for some reason required a pricey high performance ARM MCU with a a FPU and memory in the triple digit KB. When they ware told to stay in sleep mode as much as possible to not drain the battery, the result was the device sleeping for 1 second followed by running at max CPU clock for 3 seconds.On the other hand in one of my projects i end up using a PIC16F with 256 bytes of RAM and about 1.5KB of ROM to implement a motor controller with PID regulation, UI, battery management etc. The software side of things did need a fair bit of math trickery to run fast (since this MCU doesn't even have a 8bit fixed point multiply instruction) but it worked and it was dirt cheep and very low power.But not that i would be the kind of person that ONLY writes in assembly for ancient obsolete chips. I do also make use of high performance ARM MCUs or even Linux SoCs when the application needs more oomph. I just use a crappy little MCU when there is no need to use something bigger.

author: Kjelt
author_rank: Super Contributor
timestamp: August 07, 2022, 10:16:31 am
content: Quote from: Berni on August 07, 2022, 09:13:31 amThen you clearly have a mismatch for the chosen engineering team. Were theses guys embedded SW engineers or conventional SW engineers that sometimes need an embedded Linux stack before they can do anything?Any and I mean any embedded SW engineer I have encountered the last decades knows from the above two words : battery & sleepmode that there is a need for a low power uC. This does not always have to mean low performance though, nowadays there are Arm 32 bits cortex uCs that have way lower standby and sleep power usage than conventional 8 bit uCs.So yeah I see your point in this example.

author: emece67
author_rank: Frequent Contributor
timestamp: August 07, 2022, 11:31:46 am
content: .

author: Siwastaja
author_rank: Super Contributor
timestamp: August 07, 2022, 12:37:51 pm
content: Quote from: emece67 on August 07, 2022, 11:31:46 amExactly, and this is pretty obvious, and one must understand VHDL/Verilog is higher level language, not FPGA configuration language.If you target FPGA's and you think you are outsmarting the synthesizer by writing explicit muxes and and/or/not gates etc., you already are mentally lost because FPGAs do not come with muxes and gates (instead, you must look at the datasheet to understand what exact LUTs / logic elements they use, and not all details are even available).If you were to manually control what gets synthesized, then you would need to work with LUTs and manual FPGA routing. Obviously no one does that, so trying to do somethingsimilarin VHDL is just totally erratic behavior: these people are writing low-level constructs for imaginary hardware,which do not map to their actual hardware, without even realizing their mistake. With higher level code, compiler would have better chances to produce optimum result, and you have the same level of control over specifics: you can add constraints such as clock speed or logic element usage limit for the compiler. Hand-optimizing, when truly needed (which is very rare) would then have to go through the compiler constraints, instead of trying random modifications in VHDL and hoping they give the desired result. There is too much randomness in the compilers for this to work, you don't even need to change the compiler version,anychange in the project may suddenly change the number of muxes / adders used.

author: hans
author_rank: Super Contributor
timestamp: August 07, 2022, 04:24:05 pm
content: QuoteFor many modern synthesis tools, just clicking the "Resynthesize" button is enough. Not a single LOC change is necessary for a completely different output. Synthesis time is actually a big problem for large projects, and considering the synthesis problem is NP-hard complex, logically heusterics are used to cut down the massive tree of possible design implementations to something that can finish within a few minutes to hours time. I've had plenty of cases where the synthesizer complains it cannot synthesize the design for a given clock constraint, but if you hit the resynthesize button a few times, you may get lucky 1 out of 5 or 10 times. Obviously it's not a desirable workflow, but it is what it is. It shows how non-deterministic these tools can be, and with that, also good in (out)smarting or surprising the designer.Perhaps the example I gave was too simple to show a real difference on a FPGA. On an ASIC workflow I've seen the difference for a similar example. In fact, going to low-level designs, I've spoken to plenty of colleagues that were so fed up with the RNG of the synthesizer that at some point they 'manually' copy-pasted synthesized subparts of their arithmetic algorithms directly on the PDK/cell library they were using. This way, if they needed to resimulate their design post-layout, atleast they got somewhat repeatable results.But perhaps that's also working with isolated implementations and pushing boundaries on them within academia.

author: nctnico
author_rank: Super Contributor
timestamp: August 07, 2022, 04:31:06 pm
content: In my experience a design that doesn't place & route 'reliably' has issues in the timing constraints which make it hard for the 'place & route' process to get to a result. But I concur that some of this stuff is like black magic. Sometimes changing the random seed to the place & route can make the difference between having to wait for 2 hours and still not meeting timing or having the design ready in 20 minutes with all constraints met.And sometimes you do need to nudge the place & route in the right direction by anchoring some parts of the logic in certain places so it makes the right decission at some points during place & route. See it as setting the order of the place & route process.

author: westfw
author_rank: Super Contributor
timestamp: August 08, 2022, 01:25:57 am
content: Quotewe WERE talking about problem spaces where people wanted "some FPGA fabric" in their microcontroller.That's well past the point (IMO) where either HW or SW team would want to use a Linux controller for a low-power application. I hope.

author: Berni
author_rank: Super Contributor
timestamp: August 08, 2022, 05:55:39 am
content: It is more that you don't always have programmers that actually can/want to mess with low level stuff.Here schools that teach programing teach it it more around the high level stuff. Arguably most software developers end up developing things that run on powerful machines like PCs, servers, phones...etc so it does make sense. But they don't expose them very much to embedded software development where they need to work together with hardware. It is also easier to run a computer lab with a bunch of x86 PCs rather than MCU dev boards. So they will come in with an expectation that processing power and memory is essentially infinite and OS would take care of any low level nitty gritty.From my experience most of these programmers absolutely hate dealing with hardware drivers. They can't single step trough what the peripheral is doing, all they see are some changing values in a register, it is a mysterious black box that sometimes does what they want and sometimes not. So no surprise they run from HDL like the devil from the cross. So you can see how adding FPGA like features into a MCU is not popular with them.So circling back to the thread topic this is why lots of people will avoid crappy tiny microcontrollers. They can't even imagine how you could do anything useful using 256 bytes of RAM. All of the code they compile already takes up 10KB of flash when doing almost nothing because of all the standard libraries that are dragged in. Yes given how cheep ARM MCUs have gotten (well... before the chip shortage at least) it makes sense to use a overpowered MCU in a lot of cases, but there are still really dumb applications that are easily done by a crappy little 8bit MCU at much lower cost and even lower power.

author: Kjelt
author_rank: Super Contributor
timestamp: August 08, 2022, 06:34:42 am
content: Quote from: Berni on August 08, 2022, 05:55:39 amThose are completely different graduation trajects here.You have electronics, technical electronic computer science, embedded systems and Informatics to name a few.fThen you have two levels: college BSc and university MSc.You have exceptions but the BSc have more down to earth practical experience and the MSc are more theoretical.The pure hw electronics guys (generalisation) are also not very good in embedded software such that they have no knowledge about design patterns, state machine implementations, etc. The informatics people learn their stuff on high powered pc's so indeed unless they hobby at home don't know about the small stuff etc.These are generalisations and it all boils down to the person and his/her interest and also hobbie knowledge.You don't let an power electronics guy with the last five years of megawatt power installations design your emc sensitive 8 layer board.The same you don't let an informatics guy handle microcontroller choice or even the HSI, HAL interfaces and implementations. However you can give him a task to optimize some higher level library or design / optimize the complete software architecture so it stays easily expandable in the future.But it goes on, in my company you are also not a good embedded SW engineer if you have no mechanics, mechatronics and pneumatics knowledge. I do all at the momen5 for hobbie and it has given me big benefits at my job. System and domain knowledge become very important. Very simple example we had five valves to switch in some logical order. Nowhere the timeconstraints were men5ioned so my colleague sw engineer built a nice state machine that switched the valves correctly. In the review when I first saw the code I blocked the delivery since the switching was directly, there were no waiting times for releasing pressure and timing for the valve to switch (which takes multiple ms) and that is a simple example why people should always know more than what they initially were learnt at college. So in a job interview for an assignment how do you pick those people? Or are they given bij your employer?

author: Berni
author_rank: Super Contributor
timestamp: August 08, 2022, 08:02:25 am
content: Actually one of the best software developers here was someone who actually is educated as IT, but he is a smart guy that is determined to figure out whatever he needs to get the job done.He would also come to the hardware department with the most useful problem descriptions. Not only do you get a very concise and to the point description of what exactly is not working, but also a list of things he tried that support his reasoning. In most cases he indeed has narrowed down the problem rather precisely to the point where all you need to do is replace the blown chip he was suspecting and it worked. In contrast to the usual vague problem descriptions of "the ADC doesn't work", only to find later on that they forgot to set the ADC chips reset line high or they tried to run it at some absurd clock speed.It is hard to find the kind of rockstar software engineers that can make seemingly anything run on anything. So you also get a mix of good enough ones that get the job done, but need to be kept a bit more of an eye on in case they do something silly.

author: hans
author_rank: Super Contributor
timestamp: August 08, 2022, 08:54:11 am
content: Wanted to add that low-level != embedded. Sure embedded is mostly low-level, but computers can also include low-level stuff.For example, in C#, if you have a function that returns an array with no results, then a statements like ` return new int; ` or ` return Array.Empty; ` make a slight difference in memory allocation and GC objects. Array.Empty is preallocated so slightly faster (single-digit ns).All those little bits on how data is passed around, memory allocated, and cache is massaged, can make a large difference in some computation running in 5s vs 5min. To do that kind of optimization properly, you need good understanding how a modern computer works, not just understand the syntax or talk to some API.I'm sure some SW people really like the low-level stuff, and once they got their feet wet with hardware peripherals, will thrive as an embedded SW engineer.But as @Berni says, there are also people that hate writing hardware drivers as it seems like 'magic'. My brother-in-law is a backend SW engineer that works almost exclusively in JVM languages and web stuff. If I show him the edge cases and 'odd' things of C/C++ (like UB), he always laughs and suddenly has no regrets or intentions to work on some Arduino/ESP32 firmware anymore. It's not for everyone.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: September 07, 2022, 11:24:46 pm
content: Quote from: benSTmax on July 30, 2022, 09:48:09 amI fell down that hole too but only made one prototype so not as costly.I have used PIC's since 1985 and done hundreds of projects.I was a Microchip Consultant for 13 years.MPLAB X takes a while to get used to and find your way around.Plenty of choice of PIC's from 8 pin upwards.Harmony is useful for the bigger PIC's.Easier to setup hardware.Only other time got caught out was changing from pic32mx230 to pic32mx274 as one pin is input only of 274 but i/o on 230.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 08, 2022, 08:50:39 am
content: Quote from: nigelwright7557 on September 07, 2022, 11:24:46 pmI got caught by that one recently when I had to use a 174 instead of 170 due to chip shortage. Datasheet was far from clear on that . Also wasted a day getting my bootloader running as the old datasheet I was using had the wrong page size. Stupid thing is I already had the later datasheet from when I was investigating the first issue

author: free_electron
author_rank: Super Contributor
timestamp: September 08, 2022, 06:31:36 pm
content: Quote from: mikeselectricstuff on August 06, 2022, 01:02:58 pmthe problem is not with the HDL... the problem is the disconnect between software and hardware. 50 years ago you needed to understand the processor and know what bit to flick. now you install half a gigabyte of OS , plonk a VM on that and then run an interpreter on top of that... and complain it is slow.it's layer upon layer of virtualisation. and it fits like pliers on a pig.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: November 10, 2022, 04:06:37 pm
content: I picked an ATMEL device for a USB oscilloscope.Got pcb made and built one up.The USB refused to work.I got in touch with microchip and they said 64 pin version of that device doesnt work with USB.I told them RS Components description said it does and so does datasheet.They just pointed me to device errata sheet where it says it doesn't work with USB.So always pays to read device errata sheet before choosing a device for PIC's and ATMEL devices.Some of these devices are highly complex so bugs can creep in.

author: free_electron
author_rank: Super Contributor
timestamp: November 10, 2022, 04:50:44 pm
content: Quote from: nigelwright7557 on November 10, 2022, 04:06:37 pmthat's true for ANY device out there.And don;t stick to the first page only... that is just the marketing bullshit.ad9850 dds : up to 80Mhz , works from 3.3 to 5 volt. try getting 80Mhz out of it at 3.3 volt ... doesn't work ! buried deep in the datasheetsame thing for those little 6 pin isolated transformer drivers ( maxim , TI) work from 3.3 to 5 volt.. yes, but only one application diagrom shofs the 3.3 volt implementation : you need two additional diodes and a capacitor to create a boost pump for the internal logic ... there is not a single word in the entire datasheet about that little gotcha ! all the app diagrams are 5 volt , aprt from one at 3.3 and that shows you need the diode pump...the giveaway is "up to" that should be a red flag immediately.

author: Kleinstein
author_rank: Super Contributor
timestamp: November 10, 2022, 11:01:21 pm
content: Errata are common and in some case the limitation can be severe (like some HW functions not working, including things advertised on the front page). Some bugs get fixed while others are there to stay (e.g. with essentially all the AVRs the supposedly available internal capacitors for a crystal don't work).Currently the most common errata is a delivery date somewhere in the 2nd half of 2023 or later.

author: IDEngineer
author_rank: Super Contributor
timestamp: November 11, 2022, 12:03:15 am
content: I would amend that statement to say "The most common errata is a delivery date within the next six months".

author: brucehoult
author_rank: Super Contributor
timestamp: November 11, 2022, 12:12:36 am
content: Quote from: free_electron on November 10, 2022, 04:50:44 pmThat's .... absolutely standard ... for just about anything.Take the trusty ATMega328P. 4 MHz at 1.8 V, 20 MHz at 4.5 V or above (up to 5.5). Fairly linear between 1.8 V and 4.5 V e.g. 10 MHz at 2.7 V (dead linear would need 2.81V).For what device do you not expect something like this?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 11, 2022, 02:04:03 am
content: Quote from: brucehoult on November 11, 2022, 12:12:36 amProbably more that they didn't make it very clear in the datasheet, in very many places, etc. To their credit, Atmel makes it clear multiple times!Tim

author: brucehoult
author_rank: Super Contributor
timestamp: November 11, 2022, 02:24:03 am
content: Quote from: T3sl4co1l on November 11, 2022, 02:04:03 amI couldn't find an 80 MHz part, but here a 125 MHz one:https://www.analog.com/media/en/technical-documentation/data-sheets/ad9850.pdfLiterally the FIRST TWO LINES in the specifications:CLOCK INPUT CHARACTERISTICS5 V supply .... 125 MHz3.3 V supply ... 110 MHzOn page 7, graphs TPC 8, TPC 9, TPC 11 show lines for 3.3 V and 5 V, on which the 3.3 V line ends at 110 MHz not 125 MHz

author: JPortici
author_rank: Super Contributor
timestamp: November 11, 2022, 04:52:02 am
content: Quote from: brucehoult on November 11, 2022, 12:12:36 ammost PICs don't have that limit anymore

author: brucehoult
author_rank: Super Contributor
timestamp: November 11, 2022, 09:32:41 am
content: Quote from: JPortici on November 11, 2022, 04:52:02 amYou mean you don't have the *option* to run them at lower voltage / energy consumption if you don't need maximum clock speed?

author: Siwastaja
author_rank: Super Contributor
timestamp: November 11, 2022, 09:38:36 am
content: Quote from: brucehoult on November 11, 2022, 12:12:36 amYeah, and pretty standard for datasheets is that headline numbers do not apply simultaneously. For example, maximum Id and maximum Vds for MOSFETs. Or full temperature range and max power dissipation for resistors. Any designer learns this during first few years of designing.

author: Kleinstein
author_rank: Super Contributor
timestamp: November 11, 2022, 09:51:25 am
content: The speed rating changing with supply voltage is normal with CMOS chips. It depends on the chips how much the supply can vary.With some newer µCs the actual core is running at a lower, internally regulated voltage and than the maximum speed obviously no longer changes for the regulated supply part.Another point may be that the specs may just not include possibly higher speed under certain conditions. They have to limit the specs to a resonable simplified conditions, so usually not seprate speed ratings for different temperatures, even though they may allow a higher speed in some ranges.

author: JPortici
author_rank: Super Contributor
timestamp: November 11, 2022, 10:41:08 am
content: Quote from: brucehoult on November 11, 2022, 09:32:41 amI mean that they can run full speed across the whole voltage and temperature range, MCU core is running at 1V8 internally anyway

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 11, 2022, 04:02:56 pm
content: Which includes several lines from MCP now; PIC (which?) and AVR-Dx I know of?Tim

author: Siwastaja
author_rank: Super Contributor
timestamp: November 11, 2022, 04:04:48 pm
content: Quote from: Kleinstein on November 11, 2022, 09:51:25 amYes - such MCUs usually come with a configuration register which adjusts the regulator output voltage, and hence maximum clock speed and power consumption.

author: free_electron
author_rank: Super Contributor
timestamp: November 11, 2022, 06:32:03 pm
content: Quote from: brucehoult on November 11, 2022, 02:24:03 amlook for the rev A datasheet... this was like 15 or more years ago when these things first came out.