Hacker News new | past | comments | ask | show | jobs | submit | jaydcarlson's comments login

The problem is that by your definition, every processor manufactured in the last 30 years should actually be called a "microcontroller"

Microprocessors going back to the Intel 486 have more on-chip RAM than many microcontrollers sold today have. CPUs have built-in firmware ROM for loading boot code. Also, CPUs haven't had a system bus with address/data pins for like 30 years — somewhat ironically, the only chips that have that are microcontrollers. Northbridges haven't existed for 15 years, and southbridges are basically just PCIe-to-USB/SATA/Ethernet/I2C adapters. And many mobile CPUs that Intel and AMD make have on-chip I2C, SPI, UART, GPIO peripherals.

In my article, I'm trying to differentiate between processors that can run a modern multiuser operating system like Linux and microcontrollers that runs bare-metal code, since that's a question I get asked a ton. After carefully considering all the options, the MMU seemed like the most obvious place to draw the line. Every CPU in the last 40 years (since the Intel 286) has had an MMU, while no microcontroller ever made has had one. I'm not sure why that seems so unreasonable to you.


It is unreasonable because you redefine "Microprocessor" in a way that the 8086, the one that made the word popular, isn't one anymore.

Surely odd, but tolerable. But what is worse that people will read your article, think the MMU is what makes a microprocessor. And upon hearing that the 8086 has no MMU, they will deny that it is a microprocessor. Which would be a logical conclusion from your article.

I listed some other words here that suffer from similar issues https://news.ycombinator.com/item?id=30278936


Please don't quote me out of context: "these raw parts" referred to the MediaTek parts specifically, not all the parts in this review.

The only thing that SOMs provide is a processor + DRAM + PMIC. If you practice and become proficient at designing around application processors, it should take you no longer than 3-4 hours to get this component of the system (the processor, DRAM, and PMIC) laid out when working with these entry-level parts.

SOMs aren't some magical remedy to all the problems. It's still up to you to design the actual system, which takes hundreds of hours. The difference between using a SOM or a raw-chip design is negligible at this point.

I have no problem prototyping on EVKs --- in fact, I link to EVKs for each platform in my review. But a lot of these evaluation boards are pretty crummy to prototype with; some don't have all the pins of the CPU brought out, others use proprietary connectors that are a hassle to adapt to your hardware. You shouldn't be afraid to spend an 8-hour day designing a little breakout board for a part if you're interested in using it in a product that's going to span 6-months' worth of development time.

Of course there are caveats. I'm entirely focused on entry-level parts; if you need a Cortex-A72 with a 128-bit-wide dual-rank DRAM bus, sure, go buy a SOM. Also, it should go without saying that it completely depends on you and your company's core competencies. This article is aimed at embedded designers who are usually working on hardware and software for microcontroller-based platforms. If you work at a pure software shop with no in-house EE talent then this article is likely not relevant to you.


I think there's a lot of companies scared to roll out application processors instead of microcontrollers. I wonder what your thoughts are on if it can save development time due to Linux dev environment Vs baremetal.

Obviously lots of applications it would be impossible to use a 264 bga but I've been there with projects with 3 CAN buses and Ethernet plus flash memory and thought maybe we should be using a cortex A7.

I'm sure you know but file storage on microcontrollers can drive you insane ha ha and the same with graphics+TCP IP


Hi Jay, that wasn't my intent. Thanks for clarifying your scoped comment. Your post is very interesting. However, I believe the core point regarding the potential commercial questionability of embarking on EE design work with a processor part-centric mentality still stands. As you point out, it is sometimes justified. Few people outside of Asia have competent "in-house EE talent" idling in their organization.


None of these application processors I reviewed have out-of-order execution. Cortex-M7 microcontrollers have icache/dcache. You can run bare-metal code on any of these application processors and it will behave more or less like a microcontroller. The lines are really pretty blurry, but the MMU is the big dividing line in my opinion (but it's obviously open for discussion).


> None of these application processors I reviewed have out-of-order execution.

You're right, I was thinking of the A8, A9 and similar.

> the MMU is the big dividing line in my opinion

I'm no expert, but seems like a reasonable line in the sand to me.


"MMUless" was intended as a nonrestrictive modifier --- I'll remove it to avoid ambiguity. Microcontrollers tend to be built on larger processes than microprocessors are, so they eat through more active-mode power. The point I'm trying to get across is while you can run Linux on a microcontroller (which doesn't have an MMU), there's not a lot of good reasons to do so. Thanks for the feedback!


I've made some network changes, and the site should be back up for most users — let me know if anyone is running into issues!


My article includes the Holtek HT-66, the STCmicro STC8, the Nuvoton N76, and the ST STM8 — all hover in the 1-2 RMB range (especially when purchased in volume from within the mainland).

The STC8 and N76 parts are 8051, the other two are their own design. The HT-66 looks very much like a PIC16 part, and IDE and compiler are totally free.

The STM8 is probably the best-performing part in that price range, and has a free IDE and compiler.

My review includes pretty extensive discussion on the main page, plus separate reviews for all these parts — check it out and let me know if I need to clarify anything!


This is a great blog post but I'd also like to throw in that the STM line has a pretty great linux toolchain (official or not, I'm not sure).

I made a repository for the toolchain necessary to get STM boards working here: https://github.com/abraithwaite/STM32

Although it's outdated, the links at the bottom appear to link to updated tools which are presumably better :-)


Yeah, the STM8S003 is pretty hard to beat around $0.25, with excelent code-density, free IAR development and a very assembly-friendly architecture.


With 21 of these parts on my desk, that would have been a good idea. Thanks for linking to a cached version — I'm working to get my little blog on Cloudflare to handle the traffic.

I appreciate the kind words from everyone so far; it's been a huge learning opportunity, and I hope others can get inspired to grab one of these parts (especially one of the weirder ones) and do something cool with it.


While you are at it, here is how your little blog looks to those of us who browse with javascript off for security reasons:

https://pixady.com/image/0jab/

Even though all the text content is present (this image is disabling CSS and scrolling down a little):

http://pixady.com/image/0jad/

Requiring javascript for rendering what basic HTML already renders is not a very inviting or inclusive way to go with the blog.


Not your issue, but the current timeout Cloudflare page is saying that thanks to it's "Always Online™" technology, we can surf a snapshot of the site. But there is link or option to said snapshot :/


I would pay for a book version of this work, or at least a PDF that I could print. It would be the kind of book that I could really get into. Fantastic work.


I'd like to second that. I skimmed through this yesterday and about to board a long flight. Frantically caching :-p


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: