On Sat, 28 Feb 2009 12:08:11 +0000, Nobody <n...@nowhere.com> wrote:

>On Fri, 27 Feb 2009 21:57:35 -0800, John Larkin wrote:
>
>>>> That's where minimal abstraction and maximal flatness become
>>>> particularly important. It's easier to understand and maintain if
>>>> everything is in plain sight.
>>>
>>>That only works if it's feasible to comprehend the design in its entirety.
>>>For a few KiB of uc code, that's realistic. For large scale desktop or
>>>server packages, it isn't.
>> 
>> This is sci.electronics.design. Most of the stuff we do meets that
>> description. Why abstract setting a bit in a register (which I've seen
>> people do) when you can set the bit in the register?
>
>Not everything related to hardware is that simple.
>
>A single-module program may be fine for a PIC/AT8 which is doing the work
>of, say, a dozen 7400/4000 logic chips.
>
>But consider a couple of levels above that, where you might be performing
>complex DSP, providing a substantial user interface, interfacing with USB,
>BlueTooth, TCP/IP, etc, possibly needing to write a Windows driver to
>interface your hardware with a PC.

I recently did...

http://www.highlandtechnology.com/DSS/T346DS.html

which has over 250 distinct serial ascii commands, and I'm just
finishing a serious upgrade to this,

http://www.highlandtechnology.com/DSS/T560DS.html

which is code I hadn't touched for about two years. Organization and
commenting are a lot more important than languages and tools.


>
>At this level, it's still at least as much electronics as it is
>programming. Someone with no h/w experience is going to have difficulty
>doing this. The lowest level most Comp.Sci. courses touch is "systems"
>programming, and even that doesn't get into details on IRQ handling,
>bit-banging and the like (no assembler, either).

We're advertising for an embedded products programmer now. I got about
100 resumes from a Craigslist ad. Most are high-level types,
Windows/Linux/Ruby-on-rails/SQL/Web/C++ types, totally abstracted from
the CPU and hardware itself.  

About 5 of the applicants look worth interviewing, and they are all
old farts like me. Kids these days!

John

 

On a sunny day (Sat, 28 Feb 2009 09:55:21 -0800) it happened John Larkin
<j...@highNOTlandTHIStechnologyPART.com> wrote in
<i...@4ax.com>:

>I recently did...
>
>http://www.highlandtechnology.com/DSS/T346DS.html
>
>which has over 250 distinct serial ascii commands, and I'm just
>finishing a serious upgrade to this,
>
>http://www.highlandtechnology.com/DSS/T560DS.html
>
>which is code I hadn't touched for about two years. Organization and
>commenting are a lot more important than languages and tools.

A question, just to break in here,
but relevant to this discussion.:
Do you also provide the PC side, with some sort of GUI,
or does the customer have to learn ad dig all RS232 commands to
be able to for example create a simple pulse?

In my view both are always together, unless fro very very specific cases
where the customer does not _want_ the GUI.

All other projects I have done had both a PC side software and an embedded side.
The PC side can be very very complex, I like to put as much there as possible,
because it has no constraints as far as memory and speed is concerned.

A simple example is 'col_pic', the embedded side drives the LEDs, and is
controlled via RS232 from a GUI, or audi processor:
 http://panteltje.com/panteltje/pic/col_pic/
 http://panteltje.com/panteltje/xpequ/

Without the PC side where would the user be?
Like a car with engine but without dashboard :-)