Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30673
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: 64-bit embedded computing is here and now |
| Date | 2021-06-08 13:04 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <s9nir0$k47$1@dont-email.me> (permalink) |
| References | <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com> <87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me> <s9n6rb$t19$1@dont-email.me> |
On 08/06/2021 09:39, Don Y wrote: > On 6/7/2021 10:59 PM, David Brown wrote: >> 8-bit microcontrollers are still far more common than 32-bit devices in >> the embedded world (and 4-bit devices are not gone yet). At the other >> end, 64-bit devices have been used for a decade or two in some kinds of >> embedded systems. > > I contend that a good many "32b" implementations are really glorified > 8/16b applications that exhausted their memory space. Sure. Previously you might have used 32 kB flash on an 8-bit device, now you can use 64 kB flash on a 32-bit device. The point is, you are /not/ going to find yourself hitting GB limits any time soon. The step from 8-bit or 16-bit to 32-bit is useful to get a bit more out of the system - the step from 32-bit to 64-bit is totally pointless for 99.99% of embedded systems. (Even for most embedded Linux systems, you usually only have a 64-bit cpu because you want bigger and faster, not because of memory limitations. It is only when you have a big gui with fast graphics that 32-bit address space becomes a limitation.) A 32-bit microcontroller is simply much easier to work with than an 8-bit or 16-bit with "extended" or banked memory to get beyond 64 K address space limits. > >> We'll see 64-bit take a greater proportion of the embedded systems that >> demand high throughput or processing power (network devices, hard cores >> in expensive FPGAs, etc.) where the extra cost in dollars, power, >> complexity, board design are not a problem. They will probably become >> more common in embedded Linux systems as the core itself is not usually >> the biggest part of the cost. And such systems are definitely on the >> increase. >> >> But for microcontrollers - which dominate embedded systems - there has >> been a lot to gain by going from 8-bit and 16-bit to 32-bit for little > > I disagree. The "cost" (barrier) that I see clients facing is the > added complexity of a 32b platform and how it often implies (or even > *requires*) a more formal OS underpinning the application. Yes, that is definitely a cost in some cases - 32-bit microcontrollers are usually noticeably more complicated than 8-bit ones. How significant the cost is depends on the balances of the project between development costs and production costs, and how beneficial the extra functionality can be (like moving from bare metal to RTOS, or supporting networking). > >> cost. There is almost nothing to gain from a move to 64-bit, but the >> cost would be a good deal higher. > > Why is the cost "a good deal higher"? Code/data footprints don't > uniformly "double" in size. The CPU doesn't slow down to handle > bigger data. Some parts of code and data /do/ double in size - but not uniformly, of course. But your chip is bigger, faster, requires more power, has wider buses, needs more advanced memories, has more balls on the package, requires finer pitched pcb layouts, etc. In theory, you /could/ make a microcontroller in a 64-pin LQFP and replace the 72 MHz Cortex-M4 with a 64-bit ARM core at the same clock speed. The die would only cost two or three times more, and take perhaps less than 10 times the power for the core. But it would be so utterly pointless that no manufacturer would make such a device. So a move to 64-bit in practice means moving from a small, cheap, self-contained microcontroller to an embedded PC. Lots of new possibilities, lots of new costs of all kinds. Oh, and the cpu /could/ be slower for some tasks - bigger cpus that are optimised for throughput often have poorer latency and more jitter for interrupts and other time-critical features. > >> So it is not going to happen - at >> least not more than a very small and very gradual change. > > We got 32b processors NOT because the embedded world cried out for > them but, rather, because of the influence of the 32b desktop world. > We've had 32b processors since the early 80's. But, we've only had > PCs since about the same timeframe! One assumes ubiquity in the > desktop world would need to happen before any real spillover to embedded. > (When the "desktop" was an '11 sitting in a back room, it wasn't seen > as ubiquitous.) I don't assume there is any direct connection between the desktop world and the embedded world - the needs are usually very different. There is a small overlap in the area of embedded devices with good networking and a gui, where similarity to the desktop world is useful. We have had 32-bit microcontrollers for decades. I used a 16-bit Windows system when working with my first 32-bit microcontroller. But at that time, 32-bit microcontrollers cost a lot more and required more from the board (external memories, more power, etc.) than 8-bit or 16-bit devices. That has gradually changed with an almost total disregard for what has happened in the desktop world. Yes, the embedded world /did/ cry out for 32-bit microcontrollers for an increasing proportion of tasks. We cried many tears when then microcontroller manufacturers offered to give more flash space to their 8-bit devices by having different memory models, banking, far jumps, and all the other shit that goes with not having a big enough address space. We cried out when we wanted to have Ethernet and the microcontroller only had a few KB of ram. I have used maybe 6 or 8 different 32-bit microcontroller processor architectures, and I used them because I needed them for the task. It's only in the past 5+ years that I have been using 32-bit microcontrollers for tasks that could be done fine with 8-bit devices, but the 32-bit devices are smaller, cheaper and easier to work with than the corresponding 8-bit parts. > > In the future, we'll see the 64b *phone* world drive the evolution > of embedded designs, similarly. (do you really need 32b/64b to > make a phone? how much code is actually executing at any given > time and in how many different containers?) > We will see that on devices that are, roughly speaking, tablets - embedded systems with a good gui, a touchscreen, networking. And that's fine. But these are a tiny proportion of the embedded devices made. > >> The OP sounds more like a salesman than someone who actually works with >> embedded development in reality. > > Possibly. Or, just someone that wanted to stir up discussion... > Could be. And there's no harm in that!
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-07 07:47 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-07 14:13 -0700
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-07 22:31 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 07:59 +0200
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 00:39 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 13:04 +0200
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 17:30 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 09:17 +0200
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 03:12 -0700
Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-12 12:58 -0400
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-12 12:40 -0700
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 09:41 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 10:12 -0700
Re: 64-bit embedded computing is here and now DJ Delorie <dj@delorie.com> - 2021-06-09 13:16 -0400
Re: 64-bit embedded computing is here and now Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2021-06-09 13:44 -0400
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 22:03 +0300
Re: 64-bit embedded computing is here and now Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2021-06-09 15:22 -0400
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 12:58 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:26 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 23:12 +0300
Re: 64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-08 12:38 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 22:11 +0200
Re: 64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-08 14:25 -0700
Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-09 00:16 -0400
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 10:40 +0200
Re: 64-bit embedded computing is here and now Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-06-09 22:52 +0200
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-10 09:37 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 01:01 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 18:29 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 20:56 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 17:12 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-10 13:45 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 06:55 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-10 18:32 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 14:09 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 01:13 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 21:55 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 14:14 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-11 05:10 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 16:35 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-11 16:24 -0700
Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-14 05:41 -0400
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 16:51 -0700
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-08 18:20 -0700
Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-09 18:07 +0100
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 10:34 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:37 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:43 -0700
Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-08 15:46 +0100
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 22:18 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-08 23:39 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 18:33 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 10:59 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 21:00 +0300
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 20:55 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 22:06 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 16:00 -0700
Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-09 13:10 +0100
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 06:19 -0700
csiph-web