Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27200 > unrolled thread
| Started by | Elof Huang <elof.huang@runbox.com> |
|---|---|
| First post | 2017-09-01 14:07 +0800 |
| Last post | 2017-09-10 09:03 -0500 |
| Articles | 20 on this page of 74 — 15 participants |
Back to article view | Back to comp.arch.embedded
Embedded platforms for beginners? Elof Huang <elof.huang@runbox.com> - 2017-09-01 14:07 +0800
Re: Embedded platforms for beginners? Jack <jack4747@gmail.com> - 2017-08-31 23:22 -0700
Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-01 04:10 -0400
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-01 21:49 +1000
Re: Embedded platforms for beginners? Elof Huang <elof.huang@runbox.com> - 2017-09-02 11:57 +0800
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-02 18:25 +1000
Re: Embedded platforms for beginners? Elof Huang <elof.huang@runbox.com> - 2017-09-03 15:37 +0800
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-03 17:54 +1000
Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-03 13:49 -0400
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-02 11:41 -0400
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-03 09:44 +1000
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-02 20:39 -0400
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-03 11:16 +1000
Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-02 18:21 -0700
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-03 14:26 +1000
Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-03 02:14 -0400
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-03 17:52 +1000
Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-03 13:50 -0400
Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-03 22:20 -0700
Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-05 22:06 -0400
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-06 12:21 +1000
Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-05 22:42 -0400
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-06 14:26 +1000
Re: Embedded platforms for beginners? rickman <gnuarm@gmail.com> - 2017-09-06 01:20 -0400
Re: Embedded platforms for beginners? George Neuner <gneuner2@comcast.net> - 2017-09-03 15:58 -0400
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-04 08:00 +1000
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-03 19:13 -0400
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-04 09:58 +1000
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-03 20:16 -0400
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-04 15:13 +1000
Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-03 22:24 -0700
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-04 15:55 +1000
Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-05 14:15 +0200
Re: Embedded platforms for beginners? George Neuner <gneuner2@comcast.net> - 2017-09-05 12:35 -0400
Re: Embedded platforms for beginners? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2017-09-05 10:02 -0700
Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-05 18:13 +0100
Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-06 10:24 +0200
Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-05 17:10 -0700
Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-06 09:57 +0200
Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-05 16:57 -0700
Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-05 16:54 -0700
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-06 12:31 +1000
Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-05 19:42 -0700
Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-05 10:16 +0200
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-05 16:56 -0400
Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-04 10:46 +0100
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-05 17:09 -0400
Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-05 19:35 -0700
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-06 12:40 +1000
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-06 00:42 -0400
Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-06 08:55 +0100
Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-06 08:45 +0100
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-07 20:23 -0400
Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-08 08:42 +0100
Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-08 12:07 +0200
Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-08 11:40 +0100
Re: Embedded platforms for beginners? David Brown <david.brown@hesbynett.no> - 2017-09-08 13:24 +0200
Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-08 13:36 +0100
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-09 13:16 -0400
Re: Embedded platforms for beginners? Les Cargill <lcargill99@comcast.com> - 2017-09-10 08:53 -0500
Re: Embedded platforms for beginners? Dimiter_Popoff <dp@tgi-sci.com> - 2017-09-10 20:18 +0300
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-11 21:24 -0400
Re: Embedded platforms for beginners? Les Cargill <lcargill99@comcast.com> - 2017-09-15 22:22 -0500
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-18 11:26 -0400
Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-18 18:26 +0100
Re: Embedded platforms for beginners? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-19 14:27 -0400
Re: Embedded platforms for beginners? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-09-18 18:24 +0100
Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-03 22:30 -0700
Re: Embedded platforms for beginners? Clifford Heath <no.spam@please.net> - 2017-09-04 15:51 +1000
Re: Embedded platforms for beginners? Paul Rubin <no.email@nospam.invalid> - 2017-09-03 22:04 -0700
Re: Embedded platforms for beginners? kristoff <kristoff@skypro.be> - 2017-09-05 17:56 +0200
Re: Embedded platforms for beginners? Luke A. Guest <laguest@archeia.com> - 2017-09-10 17:10 +0100
Re: Embedded platforms for beginners? tarjei99@gmail.com - 2017-09-10 05:49 -0700
Re: Embedded platforms for beginners? Les Cargill <lcargill99@comcast.com> - 2017-09-10 09:03 -0500
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-09-05 16:54 -0700 |
| Message-ID | <874lsgn1l7.fsf@nightsong.com> |
| In reply to | #27230 |
Clifford Heath <no.spam@please.net> writes: > No, [GC is] *still* not the way to get the best from most embedded > hardware. It's an acceptable compromise, some of the time, is all that > can really be said. Sure, that's absolutely true, for big hardware as well as embedded, but we live in an era where "getting the best from the hardware" isn't an issue for most projects these days. It's been like that on desktops for decades, and it's now getting like that even for small embedded stuff. Right now I'm building what amounts to a modified LED blinky. In the old days that would have been a transistor circuit or a 555 timer. Or it could straightforwardly be done with the smallest of PIC 10Fxxxx's or whatever. But instead I'm using the Gemma M0 board that I mentioned, a 32-bit ARM cpu programmed in Python, just because it's cheap enough and it seems like the easiest approach. Sure if I was making millions of them I'd have to go down the cost reduction road, but I'm making just a handful. I'm sure the same is true of most things built by contributors here. Being able to get down to the machine level used to be the starting point of embedded programming, but now I'd consider it further down the path.
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-09-06 12:31 +1000 |
| Message-ID | <f6JrB.43206$gF2.3324@fx31.iad> |
| In reply to | #27245 |
On 06/09/17 09:54, Paul Rubin wrote: > Clifford Heath <no.spam@please.net> writes: >> No, [GC is] *still* not the way to get the best from most embedded >> hardware. It's an acceptable compromise, some of the time, is all that >> can really be said. > > Sure, that's absolutely true, for big hardware as well as embedded, but > we live in an era where "getting the best from the hardware" isn't an > issue for most projects these days. This isn't a thread about "most projects" but about how a beginner can learn to program embedded devices. It's pretty important to learn *what memory is* before you learn to let the tools manage it for you. I've seen smart graduate software engineers who've only ever used IDEs and GC languages who *don't really know* what memory is. I find that absolutely alarming. A good feel for the underlying hardware is essential to good results. Clifford Heath.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-09-05 19:42 -0700 |
| Message-ID | <87efrklf89.fsf@nightsong.com> |
| In reply to | #27254 |
Clifford Heath <no.spam@please.net> writes: > This isn't a thread about "most projects" but about how a beginner > can learn to program embedded devices. It's pretty important to > learn *what memory is* before you learn to let the tools manage it > for you. I'm just a dabbler in embedded devices, but on bigger computers it stopped being that way years ago. I work with smart productive programmers every day who do all their stuff in Python and Ruby and have never seen C code. Do I find it alarming? Well, it took me a little while to get used to. But they deliver working products that do what the customer wanted, and what else in engineering is supposed to matter? What I'm coming to believe (your judgment may well be better than mine, at least if you've done it both ways) is that it's gotten the same way with embedded devices. A coin-size MCU board that appears as a USB flash drive where you drag and drop a Python program sounds about as beginner-friendly as it gets. Another approach (recommended by Rickman) is Forth, which in some ways is similar in spirit. But the value of a self-contained system needing no extra boards and stuff is very high.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-05 10:16 +0200 |
| Message-ID | <oolmg4$630$1@dont-email.me> |
| In reply to | #27227 |
On 04/09/17 07:24, Paul Rubin wrote: > Clifford Heath <no.spam@please.net> writes: >> Generational GC relies on being able to move things between heaps, >> so object handles cannot be pointers (or rather, must be indirect). > > The handles are usually still pointers. First you copy the object to > the other heap, then later you scan it, copy the objects that the first > objects points to, and update the pointers in the first object to point > to the new locations. This is described pretty well in the SICP chapter > on metacircular evaluators (mitpress.mit.edu/sicp). > That is /one/ way to handle it. There are many others. For example, when you have pools of memory that have blocks of the same size, you might use an array and have indexes into that array as your handles. Or you might have something that is basically an address, but specifically manipulated in order to make it easily distinguishable to a garbage collector, and to avoid user code accidentally using it as a pointer. This could be as simple as adding an offset to put the value outside the valid range in the device - software bugs would then cause hard faults that can quickly be identified.
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2017-09-05 16:56 -0400 |
| Message-ID | <oongdp$54c$1@dont-email.me> |
| In reply to | #27225 |
On 09/04/2017 01:13 AM, Clifford Heath wrote: > On 04/09/17 10:16, Phil Hobbs wrote: >> On 09/03/2017 07:58 PM, Clifford Heath wrote: >>> On 04/09/17 09:13, Phil Hobbs wrote: >>>> On 09/03/2017 06:00 PM, Clifford Heath wrote: >>>>> On 04/09/17 05:58, George Neuner wrote: >>>>>> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath >>>>>> <no.spam@please.net> >>>>>> wrote: >>>>>> >>>>>>> On 03/09/17 16:14, rickman wrote: >>>>>>>> What is GC? >>>>>>> >>>>>>> Garbage collection. Make new objects and just lose them, >>>>>>> the GC will pick them up. You never know when the GC will >>>>>>> run, and you need a *lot* more memory, >>>>>> >>>>>> Those are misconceptions: there are systems that are completely >>>>>> deterministic, others that are very predictable (e.g., GC is >>>>>> schedulable in particular time slots, won't exceed given >>>>>> percentage of >>>>>> CPU time, etc.), and systems that don't need much additional memory. >>>>>> >>>>>> There even are systems that combine predictability with low memory >>>>>> overhead. >>>>> >>>>> All that is true. None of it invalidates what I said. >>>>> >>>>>>> so it's not a good way to get the most out of an MCU. >>>>>> >>>>>> I would say it it depends on the system. >>>>>> My position is that GC has no place in a small system. >>>>> >>>>> Thanks for confirming my position. >>>> >>>> Well, given that dynamic allocation has no place in small systems >>>> either, GC is a bit of a non-issue. ;) >>>> >>>>> >>>>>> OTOH, if you're talking about a complex >>>>>> system with 32-bit controller and 100s of KB (or more) of RAM ... >>>>> >>>>> Then you have resources in such excess that *you don't need* >>>>> to get the best out of it. Exactly what I said, in other words. >>>> >>>> Until it's been running long enough that the heap is fragmented into >>>> tiny, tiny bits. >>> >>> Modern generational GC compacts the heap quite effectively. >>> The only real difficulties are (a) doing that unobtrusively >>> and (b) being certain that you won't ever run out of memory >>> due to leaks. >> >> I assume that you haven't got a lot of aliased pointers running round >> your code! > > Generational GC relies on being able to move things between heaps, > so object handles cannot be pointers (or rather, must be indirect). > Languages that do it don't allow you to see the pointer as a number. > ... another reason why you can't get the most out of the hardware. Well, if nanny won't let you play with sharp objects, I guess it's hard to carve the beef. ;) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-09-04 10:46 +0100 |
| Message-ID | <Wh9rB.662459$sC5.235623@fx45.am4> |
| In reply to | #27221 |
On 04/09/17 00:13, Phil Hobbs wrote: > On 09/03/2017 06:00 PM, Clifford Heath wrote: >> On 04/09/17 05:58, George Neuner wrote: >>> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath <no.spam@please.net> >>> wrote: >>> >>>> On 03/09/17 16:14, rickman wrote: >>>>> What is GC? >>>> >>>> Garbage collection. Make new objects and just lose them, >>>> the GC will pick them up. You never know when the GC will >>>> run, and you need a *lot* more memory, >>> >>> Those are misconceptions: there are systems that are completely >>> deterministic, others that are very predictable (e.g., GC is >>> schedulable in particular time slots, won't exceed given percentage of >>> CPU time, etc.), and systems that don't need much additional memory. >>> >>> There even are systems that combine predictability with low memory >>> overhead. >> >> All that is true. None of it invalidates what I said. >> >>>> so it's not a good way to get the most out of an MCU. >>> >>> I would say it it depends on the system. >>> My position is that GC has no place in a small system. >> >> Thanks for confirming my position. > > Well, given that dynamic allocation has no place in small systems either, GC is > a bit of a non-issue. ;) "Small" is getting larger all the time :) Nowadays it isn't completely ridiculous to consider having GC on a small system - although I've never done it. >>> OTOH, if you're talking about a complex >>> system with 32-bit controller and 100s of KB (or more) of RAM ... >> >> Then you have resources in such excess that *you don't need* >> to get the best out of it. Exactly what I said, in other words. > > Until it's been running long enough that the heap is fragmented into tiny, tiny > bits. If you roll your own general purpose GC then at best you will be reinventing a wheel. In almost all cases such a wheel will be /far/ from circular. Even special purpose GCs can be a pig to get working. C/C++ as a language is, of course, a very bad starting point for a general purpose GC. Boehm made heroic efforts, and do to having to make pessimising assumptions, only managed to get it "frequently correct".
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2017-09-05 17:09 -0400 |
| Message-ID | <HO-dnaCeL9uU1TLEnZ2dnUU7-KPNnZ2d@supernews.com> |
| In reply to | #27231 |
On 09/04/2017 05:46 AM, Tom Gardner wrote: > On 04/09/17 00:13, Phil Hobbs wrote: >> On 09/03/2017 06:00 PM, Clifford Heath wrote: >>> On 04/09/17 05:58, George Neuner wrote: >>>> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath <no.spam@please.net> >>>> wrote: >>>> >>>>> On 03/09/17 16:14, rickman wrote: >>>>>> What is GC? >>>>> >>>>> Garbage collection. Make new objects and just lose them, >>>>> the GC will pick them up. You never know when the GC will >>>>> run, and you need a *lot* more memory, >>>> >>>> Those are misconceptions: there are systems that are completely >>>> deterministic, others that are very predictable (e.g., GC is >>>> schedulable in particular time slots, won't exceed given percentage of >>>> CPU time, etc.), and systems that don't need much additional memory. >>>> >>>> There even are systems that combine predictability with low memory >>>> overhead. >>> >>> All that is true. None of it invalidates what I said. >>> >>>>> so it's not a good way to get the most out of an MCU. >>>> >>>> I would say it it depends on the system. >>>> My position is that GC has no place in a small system. >>> >>> Thanks for confirming my position. >> >> Well, given that dynamic allocation has no place in small systems >> either, GC is >> a bit of a non-issue. ;) > > "Small" is getting larger all the time :) > > Nowadays it isn't completely ridiculous to consider > having GC on a small system - although I've never > done it. > > >>>> OTOH, if you're talking about a complex >>>> system with 32-bit controller and 100s of KB (or more) of RAM ... >>> >>> Then you have resources in such excess that *you don't need* >>> to get the best out of it. Exactly what I said, in other words. >> >> Until it's been running long enough that the heap is fragmented into >> tiny, tiny >> bits. > > If you roll your own general purpose GC then at best you > will be reinventing a wheel. In almost all cases such a > wheel will be /far/ from circular. Even special purpose GCs > can be a pig to get working. > > C/C++ as a language is, of course, a very bad starting point > for a general purpose GC. Boehm made heroic efforts, and > do to having to make pessimising assumptions, only managed > to get it "frequently correct". I've never felt the need for GC in an embedded system myself, and I'm sufficiently averse to midnight phone calls that I don't use dynamic allocation there either. There are probably situations where it's helpful, but I'm an instruments builder, and the MCU and memory are very rarely the cost driver. Field failures--even transient ones--are what costs money, not hardware. Having said that, I don't gold-plate the hardware either. It usually wouldn't matter to the customer, but one does have one's professional standards. ;) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-09-05 19:35 -0700 |
| Message-ID | <87ingwlfkh.fsf@nightsong.com> |
| In reply to | #27251 |
Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes: > I've never felt the need for GC in an embedded system myself.... > There are probably situations where it's helpful, but I'm an > instruments builder, and the MCU and memory are very rarely the cost > driver. I suspect that type of application uses mostly static memory, so GC wouldn't help that much even if it's available and you trust it. It's invaluable when you have lots of dynamically allocated objects moving around through the system. And yes, programs like that can have very high reliability, such as with phone switches programmed in Erlang with 40 year uptimes.
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-09-06 12:40 +1000 |
| Message-ID | <VeJrB.33523$rF2.27364@fx21.iad> |
| In reply to | #27255 |
On 06/09/17 12:35, Paul Rubin wrote: > Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes: >> I've never felt the need for GC in an embedded system myself.... >> There are probably situations where it's helpful, but I'm an >> instruments builder, and the MCU and memory are very rarely the cost >> driver. > > I suspect that type of application uses mostly static memory, so GC > wouldn't help that much even if it's available and you trust it. > It's invaluable when you have lots of dynamically allocated objects > moving around through the system. And yes, programs like that > can have very high reliability, such as with phone switches programmed > in Erlang with 40 year uptimes. Erlang is designed to fault without failing, with close to zero overhead. It's an entire world apart from most other kinds of programming. If it works for you, great! <http://erlang.org/doc/reference_manual/errors.html>
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2017-09-06 00:42 -0400 |
| Message-ID | <9ZadnQHsKIRz8zLEnZ2dnUU7-XmdnZ2d@supernews.com> |
| In reply to | #27255 |
On 09/05/2017 10:35 PM, Paul Rubin wrote: > Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes: >> I've never felt the need for GC in an embedded system myself.... >> There are probably situations where it's helpful, but I'm an >> instruments builder, and the MCU and memory are very rarely the cost >> driver. > > I suspect that type of application uses mostly static memory, so GC > wouldn't help that much even if it's available and you trust it. > It's invaluable when you have lots of dynamically allocated objects > moving around through the system. And yes, programs like that > can have very high reliability, such as with phone switches programmed > in Erlang with 40 year uptimes. > A big-ass phone switch is _not_ my idea of an embedded system. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-09-06 08:55 +0100 |
| Message-ID | <cSNrB.853496$2m7.343903@fx02.am4> |
| In reply to | #27259 |
On 06/09/17 05:42, Phil Hobbs wrote: > A big-ass phone switch is _not_ my idea of an embedded system. Typical "definitions" of "embedded system" run along the lines of "An embedded system is a computer system with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints." So it is reasonable to argue that telco stuff /is/ an embedded system. Doubly so when you look at how bits of software from different companies are cobbled and patch-panneled together.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-09-06 08:45 +0100 |
| Message-ID | <xINrB.1133730$nU3.966125@fx43.am4> |
| In reply to | #27251 |
On 05/09/17 22:09, Phil Hobbs wrote: > On 09/04/2017 05:46 AM, Tom Gardner wrote: >> On 04/09/17 00:13, Phil Hobbs wrote: >>> On 09/03/2017 06:00 PM, Clifford Heath wrote: >>>> On 04/09/17 05:58, George Neuner wrote: >>>>> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath <no.spam@please.net> >>>>> wrote: >>>>> >>>>>> On 03/09/17 16:14, rickman wrote: >>>>>>> What is GC? >>>>>> >>>>>> Garbage collection. Make new objects and just lose them, >>>>>> the GC will pick them up. You never know when the GC will >>>>>> run, and you need a *lot* more memory, >>>>> >>>>> Those are misconceptions: there are systems that are completely >>>>> deterministic, others that are very predictable (e.g., GC is >>>>> schedulable in particular time slots, won't exceed given percentage of >>>>> CPU time, etc.), and systems that don't need much additional memory. >>>>> >>>>> There even are systems that combine predictability with low memory >>>>> overhead. >>>> >>>> All that is true. None of it invalidates what I said. >>>> >>>>>> so it's not a good way to get the most out of an MCU. >>>>> >>>>> I would say it it depends on the system. >>>>> My position is that GC has no place in a small system. >>>> >>>> Thanks for confirming my position. >>> >>> Well, given that dynamic allocation has no place in small systems either, GC is >>> a bit of a non-issue. ;) >> >> "Small" is getting larger all the time :) >> >> Nowadays it isn't completely ridiculous to consider >> having GC on a small system - although I've never >> done it. >> >> >>>>> OTOH, if you're talking about a complex >>>>> system with 32-bit controller and 100s of KB (or more) of RAM ... >>>> >>>> Then you have resources in such excess that *you don't need* >>>> to get the best out of it. Exactly what I said, in other words. >>> >>> Until it's been running long enough that the heap is fragmented into tiny, tiny >>> bits. >> >> If you roll your own general purpose GC then at best you >> will be reinventing a wheel. In almost all cases such a >> wheel will be /far/ from circular. Even special purpose GCs >> can be a pig to get working. >> >> C/C++ as a language is, of course, a very bad starting point >> for a general purpose GC. Boehm made heroic efforts, and >> do to having to make pessimising assumptions, only managed >> to get it "frequently correct". > > I've never felt the need for GC in an embedded system myself, and I'm > sufficiently averse to midnight phone calls that I don't use dynamic allocation > there either. > > There are probably situations where it's helpful, but I'm an instruments > builder, and the MCU and memory are very rarely the cost driver. Field > failures--even transient ones--are what costs money, not hardware. Having said > that, I don't gold-plate the hardware either. It usually wouldn't matter to the > customer, but one does have one's professional standards. ;) No disagreement there, but the boring stuff is becoming more commonplace. By "boring" I'm thinking of fancy bitmapped GUIs and USB/networking/etc, and at GC is more likely to creep in through that kind of bling. As for MCU/memory not being a cost driver, that means they no longer preclude GC.
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2017-09-07 20:23 -0400 |
| Message-ID | <keednQXhXOCTfizEnZ2dnUU7-bGdnZ2d@supernews.com> |
| In reply to | #27262 |
On 09/06/2017 03:45 AM, Tom Gardner wrote: > On 05/09/17 22:09, Phil Hobbs wrote: >> On 09/04/2017 05:46 AM, Tom Gardner wrote: >>> On 04/09/17 00:13, Phil Hobbs wrote: >>>> On 09/03/2017 06:00 PM, Clifford Heath wrote: >>>>> On 04/09/17 05:58, George Neuner wrote: >>>>>> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath >>>>>> <no.spam@please.net> >>>>>> wrote: >>>>>> >>>>>>> On 03/09/17 16:14, rickman wrote: >>>>>>>> What is GC? >>>>>>> >>>>>>> Garbage collection. Make new objects and just lose them, >>>>>>> the GC will pick them up. You never know when the GC will >>>>>>> run, and you need a *lot* more memory, >>>>>> >>>>>> Those are misconceptions: there are systems that are completely >>>>>> deterministic, others that are very predictable (e.g., GC is >>>>>> schedulable in particular time slots, won't exceed given >>>>>> percentage of >>>>>> CPU time, etc.), and systems that don't need much additional memory. >>>>>> >>>>>> There even are systems that combine predictability with low memory >>>>>> overhead. >>>>> >>>>> All that is true. None of it invalidates what I said. >>>>> >>>>>>> so it's not a good way to get the most out of an MCU. >>>>>> >>>>>> I would say it it depends on the system. >>>>>> My position is that GC has no place in a small system. >>>>> >>>>> Thanks for confirming my position. >>>> >>>> Well, given that dynamic allocation has no place in small systems >>>> either, GC is >>>> a bit of a non-issue. ;) >>> >>> "Small" is getting larger all the time :) >>> >>> Nowadays it isn't completely ridiculous to consider >>> having GC on a small system - although I've never >>> done it. >>> >>> >>>>>> OTOH, if you're talking about a complex >>>>>> system with 32-bit controller and 100s of KB (or more) of RAM ... >>>>> >>>>> Then you have resources in such excess that *you don't need* >>>>> to get the best out of it. Exactly what I said, in other words. >>>> >>>> Until it's been running long enough that the heap is fragmented into >>>> tiny, tiny >>>> bits. >>> >>> If you roll your own general purpose GC then at best you >>> will be reinventing a wheel. In almost all cases such a >>> wheel will be /far/ from circular. Even special purpose GCs >>> can be a pig to get working. >>> >>> C/C++ as a language is, of course, a very bad starting point >>> for a general purpose GC. Boehm made heroic efforts, and >>> do to having to make pessimising assumptions, only managed >>> to get it "frequently correct". >> >> I've never felt the need for GC in an embedded system myself, and I'm >> sufficiently averse to midnight phone calls that I don't use dynamic >> allocation >> there either. >> >> There are probably situations where it's helpful, but I'm an instruments >> builder, and the MCU and memory are very rarely the cost driver. Field >> failures--even transient ones--are what costs money, not hardware. >> Having said >> that, I don't gold-plate the hardware either. It usually wouldn't >> matter to the >> customer, but one does have one's professional standards. ;) > > No disagreement there, but the boring stuff is becoming > more commonplace. By "boring" I'm thinking of fancy bitmapped > GUIs and USB/networking/etc, and at GC is more likely to > creep in through that kind of bling. > > As for MCU/memory not being a cost driver, that means > they no longer preclude GC. The primary thing that precludes GC in my embedded projects is me. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-09-08 08:42 +0100 |
| Message-ID | <%RrsB.778646$cS2.338696@fx19.am4> |
| In reply to | #27270 |
On 08/09/17 01:23, Phil Hobbs wrote: > On 09/06/2017 03:45 AM, Tom Gardner wrote: >> On 05/09/17 22:09, Phil Hobbs wrote: >>> On 09/04/2017 05:46 AM, Tom Gardner wrote: >>>> On 04/09/17 00:13, Phil Hobbs wrote: >>>>> On 09/03/2017 06:00 PM, Clifford Heath wrote: >>>>>> On 04/09/17 05:58, George Neuner wrote: >>>>>>> On Sun, 3 Sep 2017 17:52:42 +1000, Clifford Heath <no.spam@please.net> >>>>>>> wrote: >>>>>>> >>>>>>>> On 03/09/17 16:14, rickman wrote: >>>>>>>>> What is GC? >>>>>>>> >>>>>>>> Garbage collection. Make new objects and just lose them, >>>>>>>> the GC will pick them up. You never know when the GC will >>>>>>>> run, and you need a *lot* more memory, >>>>>>> >>>>>>> Those are misconceptions: there are systems that are completely >>>>>>> deterministic, others that are very predictable (e.g., GC is >>>>>>> schedulable in particular time slots, won't exceed given percentage of >>>>>>> CPU time, etc.), and systems that don't need much additional memory. >>>>>>> >>>>>>> There even are systems that combine predictability with low memory >>>>>>> overhead. >>>>>> >>>>>> All that is true. None of it invalidates what I said. >>>>>> >>>>>>>> so it's not a good way to get the most out of an MCU. >>>>>>> >>>>>>> I would say it it depends on the system. >>>>>>> My position is that GC has no place in a small system. >>>>>> >>>>>> Thanks for confirming my position. >>>>> >>>>> Well, given that dynamic allocation has no place in small systems either, >>>>> GC is >>>>> a bit of a non-issue. ;) >>>> >>>> "Small" is getting larger all the time :) >>>> >>>> Nowadays it isn't completely ridiculous to consider >>>> having GC on a small system - although I've never >>>> done it. >>>> >>>> >>>>>>> OTOH, if you're talking about a complex >>>>>>> system with 32-bit controller and 100s of KB (or more) of RAM ... >>>>>> >>>>>> Then you have resources in such excess that *you don't need* >>>>>> to get the best out of it. Exactly what I said, in other words. >>>>> >>>>> Until it's been running long enough that the heap is fragmented into tiny, >>>>> tiny >>>>> bits. >>>> >>>> If you roll your own general purpose GC then at best you >>>> will be reinventing a wheel. In almost all cases such a >>>> wheel will be /far/ from circular. Even special purpose GCs >>>> can be a pig to get working. >>>> >>>> C/C++ as a language is, of course, a very bad starting point >>>> for a general purpose GC. Boehm made heroic efforts, and >>>> do to having to make pessimising assumptions, only managed >>>> to get it "frequently correct". >>> >>> I've never felt the need for GC in an embedded system myself, and I'm >>> sufficiently averse to midnight phone calls that I don't use dynamic allocation >>> there either. >>> >>> There are probably situations where it's helpful, but I'm an instruments >>> builder, and the MCU and memory are very rarely the cost driver. Field >>> failures--even transient ones--are what costs money, not hardware. Having said >>> that, I don't gold-plate the hardware either. It usually wouldn't matter to the >>> customer, but one does have one's professional standards. ;) >> >> No disagreement there, but the boring stuff is becoming >> more commonplace. By "boring" I'm thinking of fancy bitmapped >> GUIs and USB/networking/etc, and at GC is more likely to >> creep in through that kind of bling. >> >> As for MCU/memory not being a cost driver, that means >> they no longer preclude GC. > > The primary thing that precludes GC in my embedded projects is me. And that's an incontestable reason :) Personally I've never included GC in my embedded projects (although I use it everywhere else). But my reason is different: I'm interested in the /hard/ realtime behaviour. That frequently makes it difficult for me to include things like caches and interrupts. Fortunately there /are/ alternatives.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-08 12:07 +0200 |
| Message-ID | <ootq5h$hco$1@dont-email.me> |
| In reply to | #27272 |
On 08/09/17 09:42, Tom Gardner wrote: > On 08/09/17 01:23, Phil Hobbs wrote: >> On 09/06/2017 03:45 AM, Tom Gardner wrote: >>> As for MCU/memory not being a cost driver, that means >>> they no longer preclude GC. >> >> The primary thing that precludes GC in my embedded projects is me. My main reasoning for not using garbage collection, is that my code does not generate garbage :-) > > And that's an incontestable reason :) > > Personally I've never included GC in my embedded projects > (although I use it everywhere else). But my reason is > different: I'm interested in the /hard/ realtime behaviour. > > That frequently makes it difficult for me to include things > like caches and interrupts. Fortunately there /are/ alternatives. > Usually in that kind of project, you are avoiding dynamic memory and not using any kind of malloc/free equivalent.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-09-08 11:40 +0100 |
| Message-ID | <lsusB.1240131$WI6.154044@fx30.am4> |
| In reply to | #27274 |
On 08/09/17 11:07, David Brown wrote: > On 08/09/17 09:42, Tom Gardner wrote: >> On 08/09/17 01:23, Phil Hobbs wrote: >>> On 09/06/2017 03:45 AM, Tom Gardner wrote: > >>>> As for MCU/memory not being a cost driver, that means >>>> they no longer preclude GC. >>> >>> The primary thing that precludes GC in my embedded projects is me. > > My main reasoning for not using garbage collection, is that my code does > not generate garbage :-) Lucky you; usually my code /is/ garbage :) >> And that's an incontestable reason :) >> >> Personally I've never included GC in my embedded projects >> (although I use it everywhere else). But my reason is >> different: I'm interested in the /hard/ realtime behaviour. >> >> That frequently makes it difficult for me to include things >> like caches and interrupts. Fortunately there /are/ alternatives. >> > > Usually in that kind of project, you are avoiding dynamic memory and not > using any kind of malloc/free equivalent. Agreed, although I don't object to using malloc during startup. I've always liked (and usually been able to achieve) almost complete separation between the hard realtime code and the "other stuff". Frequently the "other stuff" is coded in whatever is convenient, which usually includes GC.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-08 13:24 +0200 |
| Message-ID | <ootulp$bne$1@dont-email.me> |
| In reply to | #27276 |
On 08/09/17 12:40, Tom Gardner wrote:
> On 08/09/17 11:07, David Brown wrote:
>> On 08/09/17 09:42, Tom Gardner wrote:
>>> On 08/09/17 01:23, Phil Hobbs wrote:
>>>> On 09/06/2017 03:45 AM, Tom Gardner wrote:
>>
>>>>> As for MCU/memory not being a cost driver, that means
>>>>> they no longer preclude GC.
>>>>
>>>> The primary thing that precludes GC in my embedded projects is me.
>>
>> My main reasoning for not using garbage collection, is that my code does
>> not generate garbage :-)
>
> Lucky you; usually my code /is/ garbage :)
>
>>> And that's an incontestable reason :)
>>>
>>> Personally I've never included GC in my embedded projects
>>> (although I use it everywhere else). But my reason is
>>> different: I'm interested in the /hard/ realtime behaviour.
>>>
>>> That frequently makes it difficult for me to include things
>>> like caches and interrupts. Fortunately there /are/ alternatives.
>>>
>>
>> Usually in that kind of project, you are avoiding dynamic memory and not
>> using any kind of malloc/free equivalent.
>
> Agreed, although I don't object to using malloc
> during startup.
Yes, that's fair enough (though I prefer static allocation when possible
- it makes it easier to see memory usage in map files. And for less
capable microcontrollers, it can be more efficient).
I have used systems where the malloc/free system is implemented as
something like :
static uint8_t heap[HEAP_SIZE];
static uint8_t * heapPointer;
void * malloc(size_t size) {
if ((&heap[HEAP_SIZE] - heapPointer) < size) {
die_horribly();
}
uint8_t * p = heapPointer;
heapPointer += size;
return p;
}
void free(void * ptr) {
die_horribly();
}
>
> I've always liked (and usually been able to achieve)
> almost complete separation between the hard realtime
> code and the "other stuff". Frequently the "other stuff"
> is coded in whatever is convenient, which usually
> includes GC.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-09-08 13:36 +0100 |
| Message-ID | <X8wsB.989668$ZZ2.736547@fx08.am4> |
| In reply to | #27277 |
On 08/09/17 12:24, David Brown wrote:
> On 08/09/17 12:40, Tom Gardner wrote:
>> On 08/09/17 11:07, David Brown wrote:
>>> On 08/09/17 09:42, Tom Gardner wrote:
>>>> On 08/09/17 01:23, Phil Hobbs wrote:
>>>>> On 09/06/2017 03:45 AM, Tom Gardner wrote:
>>>
>>>>>> As for MCU/memory not being a cost driver, that means
>>>>>> they no longer preclude GC.
>>>>>
>>>>> The primary thing that precludes GC in my embedded projects is me.
>>>
>>> My main reasoning for not using garbage collection, is that my code does
>>> not generate garbage :-)
>>
>> Lucky you; usually my code /is/ garbage :)
>>
>>>> And that's an incontestable reason :)
>>>>
>>>> Personally I've never included GC in my embedded projects
>>>> (although I use it everywhere else). But my reason is
>>>> different: I'm interested in the /hard/ realtime behaviour.
>>>>
>>>> That frequently makes it difficult for me to include things
>>>> like caches and interrupts. Fortunately there /are/ alternatives.
>>>>
>>>
>>> Usually in that kind of project, you are avoiding dynamic memory and not
>>> using any kind of malloc/free equivalent.
>>
>> Agreed, although I don't object to using malloc
>> during startup.
>
> Yes, that's fair enough (though I prefer static allocation when possible
> - it makes it easier to see memory usage in map files. And for less
> capable microcontrollers, it can be more efficient).
>
> I have used systems where the malloc/free system is implemented as
> something like :
>
> static uint8_t heap[HEAP_SIZE];
> static uint8_t * heapPointer;
>
> void * malloc(size_t size) {
> if ((&heap[HEAP_SIZE] - heapPointer) < size) {
> die_horribly();
> }
> uint8_t * p = heapPointer;
> heapPointer += size;
> return p;
> }
>
> void free(void * ptr) {
> die_horribly();
> }
Yes indeed.
In one system I built, the client looked through
squinty eyes (but also had a wry smile) at a function
of mine called void expire().
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2017-09-09 13:16 -0400 |
| Message-ID | <u_udnUtyda2fvynEnZ2dnUU7-UXNnZ2d@supernews.com> |
| In reply to | #27277 |
On 09/08/2017 07:24 AM, David Brown wrote:
> void free(void * ptr) {
> die_horribly();
> }
My big brother used to say that the tape drives on the IBM System/360 at
his school had an undocumented instruction: SST, for Stop and Stretch
Tape. Other systems were rumoured to have HCF, for Halt and Catch Fire. ;)
Of course back then there were Real Programmers like Mel Kaye.
http://www.catb.org/jargon/html/story-of-mel.html
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
hobbs at electrooptical dot net
http://electrooptical.net
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-09-10 08:53 -0500 |
| Message-ID | <op3ftl$adr$1@dont-email.me> |
| In reply to | #27288 |
Phil Hobbs wrote:
> On 09/08/2017 07:24 AM, David Brown wrote:
>
>> void free(void * ptr) { die_horribly(); }
> My big brother used to say that the tape drives on the IBM System/360
> at his school had an undocumented instruction: SST, for Stop and
> Stretch Tape. Other systems were rumoured to have HCF, for Halt and
> Catch Fire. ;)
>
Now a major cable network series on a station near you:
http://www.imdb.com/title/tt2543312/
> Of course back then there were Real Programmers like Mel Kaye.
>
> http://www.catb.org/jargon/html/story-of-mel.html
>
>
> Cheers
>
> Phil Hobbs
>
>
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web