Re: Learning embedded systems
From: Paul E. Bennett (peb_at_amleth.demon.co.uk)
Date: 03/08/05
- Next message: Jesper: "Re: TCP/IP stack for GPRS"
- Previous message: Patrick: "Re: I2C troubleshooting"
- In reply to: Ed Beroset: "Re: Learning embedded systems"
- Next in thread: Ed Beroset: "Re: Learning embedded systems"
- Reply: Ed Beroset: "Re: Learning embedded systems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 08 Mar 2005 20:30:57 +0000
Ed Beroset wrote:
> CBFalconer wrote:
>> Ed Beroset wrote:
>>
>>>CBFalconer wrote:
>>>
>>>
>>>>weak spots. I considered and discarded C very early, and settled
>>>>on Pascal, with a complete collection of run-time and compile time
>>>>tests, and very close typing. The compilers were built to the ISO
>>>>standard, and validated against the industry test suite. You can
>>>>see some of the details on my site in the PascalP manual. As far
>>>>as I know no software or hardware errors made it into the field.
>>>>So I consider myself entitled to my strong opinions here.
>>>
>>>Do you advocate or use any tool or technique which is less than a
>>>decade old? If not, why not? If so, what is it?
>>
>>
>> I use gcc regularly :-) I even use kmeleon, which is a GUI browser
>> released this year. I also use Netscape 4.75, because AFAICS no
> [...]
>> I have absolutely no need for an IDE, when a couple of keystrokes
>> can switch me from window to window to do editing, compilation, and
>> execution. A make file customizes things very nicely. Once in a
>> while an IDE would be handy for debugging, but a few judicious
>> printfs usually suffice.
>>
>> I also regularly use furniture that appears in pictures of my
>> grandfathers home around 1900, and are presently in a house built
>> in the 18th century. Works fine, even when lighted with compact
>> fluorescent bulbs developed in the past few years.
>>
>> New is not necessarily better. It is often poorer.
>
> Nobody said that new was necessarily better. It's not necessarly worse
> either (and "often poorer" is a mischaracterization also, in my
> experience). My point in asking was just to suggest that if you haven't
> adapted to anything new in the last decade or more, maybe you're not as
> productive as you could be if you'd stretch a little more and try
> learning something new. Maybe you're happy just the way you are, but I
> know that if I was still doing things the way I was ten years ago,
> there's a lot I just plain wouldn't be able to do.
For me, who is probably not quite as close to retirement age as CB Falconer
is (judging by his CV), I find that I have not had to add very much new
stuff for my embedded work in the last decade. This does not mean that I
have stopped looking at all the new techniques, widgets and toys that come
out with great regularity, but I find few of them are relevent enough or
robust enough for the sort of High Integrity Distributed Embedded Control
Systems that I develop. It also does not mean that I have added nothing
new. Hoevever, what I have added has been quite carefully considered for
its fit with my methods and exisiting techniques and chosen for what they
will definitely add of value to me.
Of course, I am still quite inventive in both the hardware and software in
order to solve the problems that come my way. Lately, though, I have
learned more of Ultra High Vacuum Techniques, Cryogenics and Sensor
Technologies than any Uni is likely to cover. It certainly has been fun.
Incidently, I have always favoured the approach of learning what the
clients domain was all about in order to put forward the most appropriate
control systems for his needs. I mostly concentrate on the plant side stuff
and leave the user interface (whizzy graphics etc) to others who are more
comfortable doing that sort of stuff. The times I get involved in any
heavily user oriented developments is when the control scheme requires the
use of a supervisory key based interlock system (Fortress Keys etc).
Over the years I have built quite a library of techniques and component
designs that I can put together almost Lego-like to accomplish any of the
common control tasks. So, it is worthwhile keeping notes and factoring the
problems properly so that you can easily identify potentially re-usable
stuff.
Above all, have some fun doing the work. It gets dull otherwise.
-- ******************************************************************** Paul E. Bennett ....................<email://peb@amleth.demon.co.uk> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/ ********************************************************************
- Next message: Jesper: "Re: TCP/IP stack for GPRS"
- Previous message: Patrick: "Re: I2C troubleshooting"
- In reply to: Ed Beroset: "Re: Learning embedded systems"
- Next in thread: Ed Beroset: "Re: Learning embedded systems"
- Reply: Ed Beroset: "Re: Learning embedded systems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|